Hi, > > On 6 Feb 2002 at 8:38, Mensing, Joerg wrote: > > > > Hmm, so having multiple connections (one per thread) really > > > serves no useful function > > > other than to allow each thread to operate as a different user. > > > > > Who talked about a different user? I just said different > connection. It is > > possible and allowed to connected several times from within > a single client > > using the same user. > > I think we're having a language breakdown, I'm not explaining > myself here. > > Lets use a real example. Zope on Python on Linux or Windows. > > Zope spawns multiple threads. > > Each thread can share a single database connection, in which > case requests are > serialized by Zope so threads will block if there is already > a db request in progress. If SAPDB would do this, there would be no sense in using threads except for accessing separate databases...
> > Or, each thread can have it's own database connection. > Typically it's the same userid > that is used, but that's not important in our example. Each > thread has it's own database > connection and Zope will not serialize access since each > connection is independent. thats exactly how you should works with SAPDB. > > What I need to know is, will the underlying client > DLL/library serialize access from > multiple connections within the same process space. I'm not > concerned about multiple > processes being serialized since a) hope that doesn't happen, > and b) I'm using Zope > mostly. it will not serialize. > > Earlier it was said that the ODBC driver will serialize > multiple requests, but it's not clear > if that happens when multiple ODBC connections are made from > a single process, one > connection per thread. > > I understand that you're using a simple request/reply > client-server method, and only > one-outstanding-request is allowed per connection. That's okay. > > Coming from Interbase, I do have this problem where both > under Windows and Linux > the gds32 library/dll is unreliable if multiple threads are > used, even when each thread > instatiates it's own connection. thats why it is called not multithread save... You could probably get it much more stable if you write a wrapper for each call to such a DLL and protect the called procedures with a shared semaphore. This is working if the calling interfaces do not return 'global or static' storage data. In case of SAPDB client runtime, the connection is handled via buffers that are completly independend from each other. There is also no known 'common' data like statistic records etc. which could produce a conflict. Each connection will have its own signalling semaphore and will be talking to a separated 'task' inside the SAPDB kernel. So connection on SAPDB are really independend from each other once they are established... > > > As i said, you just have to open more than one connection. > The restriction > > is on a single connection you have to wait for a reply to > your request, > > before you can issue another request. And again be carefull not to > > establish connections in parallel. CU jrg > > > Ok, so you're saying that I can have multiple connections > from a single process. > Typically one connection per thread in my case. Each thread > can send a request to the > server and it won't be blocked by other thread's pending > requests because each thread > has it's own connection.. Right? yes, you are. > > However I have to be sure to not call "open connection > (whatever you call it)" from two > threads simultaneously because there's no semaphore to > control the connection list? that's it. We could protect the connection list, but it is simply not done. CU jrg _______________________________________________ sapdb.general mailing list [EMAIL PROTECTED] http://listserv.sap.com/mailman/listinfo/sapdb.general
