Icon View Thread

The following is the text of the current message along with any replies.
Messages 1 to 5 of 5 total
Thread Identifying connections from the same process
Thu, Mar 15 2007 8:48 PMPermanent 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 PMPermanent Link

Tim Young [Elevate Software]

Elevate Software, Inc.

Avatar

Email 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 PMPermanent 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 PMPermanent Link

Tim Young [Elevate Software]

Elevate Software, Inc.

Avatar

Email 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 PMPermanent 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
Image