Login ProductsSalesSupportDownloadsAbout |
Home » Technical Support » DBISAM Technical Support » Support Forums » DBISAM Client/Server » View Thread |
Messages 1 to 5 of 5 total |
Identifying connections from the same process |
Thu, Mar 15 2007 8:48 PM | Permanent Link |
Oliver Bock | I'm trying to set something up to notify my client applications when
certain events occur on the server. My idea (which has been kicked around on this newsgroup before, although I cannot find it now) is to create a separate thread on the client to make a server procedure call that will return only when the event occurs. This allows the server to send asynchronous messages to the client application without requiring connections to be initiated by the server, which won't work through firewalls. My question is: how can I work out that two server procedure calls come from the same client application? I need to know this because one thread/session will subscribe to the events, and another thread/session will wait for them. I cannot use the RemoteAddress (IP number) because multiple applications may run on a single machine. I know DBISAM has this information because it uses it to share memory tables between threads from the same process. Regards, Oliver |
Fri, Mar 16 2007 3:35 PM | Permanent Link |
Tim Young [Elevate Software] Elevate Software, Inc. timyoung@elevatesoft.com | Oliver,
<< My question is: how can I work out that two server procedure calls come from the same client application? I need to know this because one thread/session will subscribe to the events, and another thread/session will wait for them. I cannot use the RemoteAddress (IP number) because multiple applications may run on a single machine. >> I know DBISAM has this information because it uses it to share memory tables between threads from the same process. >> Yes, but unfortunately DBISAM doesn't surface this information anywhere, only the user ID and session ID. -- Tim Young Elevate Software www.elevatesoft.com |
Sun, Mar 18 2007 7:20 PM | Permanent Link |
Oliver Bock | Tim Young [Elevate Software] wrote:
> Yes, but unfortunately DBISAM doesn't surface this information anywhere, > only the user ID and session ID. Thanks Tim. OK. I'll just have to pass something unique in via both server procedure calls and the correlate it. Oliver |
Tue, Mar 20 2007 5:13 PM | Permanent Link |
Tim Young [Elevate Software] Elevate Software, Inc. timyoung@elevatesoft.com | Oliver,
<< Thanks Tim. OK. I'll just have to pass something unique in via both server procedure calls and the correlate it. >> I can see about adding something for the new DBISAM build. It shouldn't be hard to add it to the TDBISAMSession component. It might be "undocumented", but it should work. -- Tim Young Elevate Software www.elevatesoft.com |
Sun, Mar 25 2007 11:39 PM | Permanent Link |
Oliver Bock | Tim Young [Elevate Software] wrote:
> I can see about adding something for the new DBISAM build. It shouldn't be > hard to add it to the TDBISAMSession component. It might be "undocumented", > but it should work. I've worked around it now so there's no need to change it on my account. (I just allocate a GUID when my program starts and pass that through.) Thanks anyway. Oliver |
This web page was last updated on Wednesday, April 17, 2024 at 10:35 PM | Privacy PolicySite Map © 2024 Elevate Software, Inc. All Rights Reserved Questions or comments ? E-mail us at info@elevatesoft.com |