Discussion:
Informix + D2007: Connection name in use
(too old to reply)
Steve Pietrykoski
2008-02-12 01:24:32 UTC
Permalink
Borland/Codegear has a longstanding problem with its Informix DBX
drivers. The drivers do not work in pooled, multi-threaded situations,
raising an error of "Connection name is use." I am trying to make the
switch from D6 to D2007, but this is a showstopper. In D6, I switched
to a driver from Luxena, but it seems they are defunct, having no news
on their site since 2006 and not responding to email. So if anyone
knows how to work around this, that would be great.

Alternatively, if anyone has a simple demo of multi-threaded database
access they would being willing to share, I might be able to use it to
demonstrate the problem in a support case. The problem arises in my app
which is large and uses RemObjects to manage the connection pool, so
it's not feasible to derive a test case from it.

Thanks,
Steve Pietrykoski
Steven Shaughnessy
2008-02-13 05:59:29 UTC
Permalink
Do you know if only one thread at a time uses a particular connection and
all of its associated commands and readers?

Do you have a stack trace for the error?
Borland/Codegear has a longstanding problem with its Informix DBX drivers.
The drivers do not work in pooled, multi-threaded situations, raising an
error of "Connection name is use." I am trying to make the switch from D6
to D2007, but this is a showstopper. In D6, I switched to a driver from
Luxena, but it seems they are defunct, having no news on their site since
2006 and not responding to email. So if anyone knows how to work around
this, that would be great.
Alternatively, if anyone has a simple demo of multi-threaded database
access they would being willing to share, I might be able to use it to
demonstrate the problem in a support case. The problem arises in my app
which is large and uses RemObjects to manage the connection pool, so it's
not feasible to derive a test case from it.
Thanks,
Steve Pietrykoski
Steve Pietrykoski
2008-02-13 18:42:20 UTC
Permalink
Steven,

The call stack follows. I believe RemObjects has threads listening for
client requests, which check the pool of available service instances to
see if any are available to handle the request. The service instances
are essentially datamodules, each containing a TSQLConnection and
datasets; presumably they each run in their own thread. Any given
request is handled by one instance, but the instances can handle
requests from any client.

FWIW, Luxena added the following parameter to their connection string,
and it was this (set to INTERTHREADED) that made it work for me:

THREAD MODE defines usage mode in threads. Informix connectivity
allows only one active connection per thread, so if more than one
connection are used in thread or connection is used in several threads,
application must switch active connection for an execution thread. ONE
PER THREAD, MANY PER THREAD, INTERTHREADED (FETCH OPTIMIZED) and
INTERTHREADED.
Default is INTERTHREADED (FETCH OPTIMIZED).


:7c812a5b kernel32.RaiseException + 0x52
DBXCommon.TDBXContext.Error(???,'Connection name in use.'#$A)
DBXDynalink.TDBXMethodTable.RaiseError($1AEB290,101,???,'')
DBXDynalink.TDBXDynalinkCommand.CheckResult(???)
DBXDynalink.TDBXDynalinkCommand.DerivedPrepare
DBXCommon.TDBXCommand.Prepare
DBXDelegate.TDBXMorphicCommand.Prepare
SqlExpr.TCustomSQLDataSet.PrepareStatement
SqlExpr.TCustomSQLDataSet.SetPrepared(True)
SqlExpr.TCustomSQLDataSet.OpenCursor(???)
DB.TDataSet.SetActive(???)
DB.TDataSet.Open
Provider.TDataSetProvider.InternalGetRecords(-1,0,[grMetaData],'',Null)
Provider.TCustomProvider.DoGetRecords(-1,0,1,'',Null,'')
Provider.TCustomProvider.GetRecords(???,0,1,'',Null,'')
uRODataSnapBaseAppServer.TRODataSnapBaseAppServer.AS_GetRecords('prvOrgLevels',-1,0,1,'',$1F2AB80,'')
uRODataSnap_Invk.TAppServer_Invoker.Invoke_AS_GetRecords(Pointer($1EF1D00)
as IInterface,Pointer($1A8436C) as IROMessage,Pointer($1A9AA40) as
IROTransport,[])
uROServer.TROInvoker.CustomHandleMessage(TROClassFactory($1AD5298) as
IROClassFactory,Pointer($1A8436C) as IROMessage,Pointer($1A9AA40) as
IROTransport,[])
uROServer.TROInvoker.HandleMessage(TROClassFactory($1AD5298) as
IROClassFactory,Pointer($1A8436C) as IROMessage,Pointer($1A9AA40) as
IROTransport,[])
uROServer.MainProcessMessage(Pointer($1A8436C) as
IROMessage,Pointer($1A9AA40) as IROTransport,$1F17750,$1F17CF0,[])
uROServer.TROMessageDispatcher.ProcessMessage(Pointer($1A9AA40) as
IROTransport,$1F17750,$1F17CF0,[])
uROServer.TROServer.IntDispatchMessage($1F0DA38,Pointer($1A9AA40) as
IROTransport,$1F17780,$1F17720,[])
uROServer.TROServer.DispatchMessage(Pointer($1A9AA40) as
IROTransport,$1F17780,$1F17720,[])
uROServer.TROServer.DispatchMessage(Pointer($1A9AA40) as
IROTransport,$1F17780,$1F17720)
uROSuperTCPServer.TROInvokerQueueItem.Callback($1A4BF40,$1ABF1F0)
uROThreadPool.TROPooledThread.Execute
Classes.ThreadProc($1ABF1F0)
System.ThreadWrapper($1AC7E20)
:7c80b683 ; C:\WINDOWS\system32\kernel32.dll
Post by Steven Shaughnessy
Do you know if only one thread at a time uses a particular connection and
all of its associated commands and readers?
Do you have a stack trace for the error?
Borland/Codegear has a longstanding problem with its Informix DBX drivers.
The drivers do not work in pooled, multi-threaded situations, raising an
error of "Connection name is use." I am trying to make the switch from D6
to D2007, but this is a showstopper. In D6, I switched to a driver from
Luxena, but it seems they are defunct, having no news on their site since
2006 and not responding to email. So if anyone knows how to work around
this, that would be great.
Alternatively, if anyone has a simple demo of multi-threaded database
access they would being willing to share, I might be able to use it to
demonstrate the problem in a support case. The problem arises in my app
which is large and uses RemObjects to manage the connection pool, so it's
not feasible to derive a test case from it.
Thanks,
Steve Pietrykoski
Rich Werning
2008-02-19 15:46:03 UTC
Permalink
For what its worth, we used Corelab drivers for our Oracle and SqlServer
databases for years. With the new dbExpress4 in D2007 I decided to let our
subscription lapse and switch to Codegears drivers. After a couple months
of testing and usage, we've switched back to the Corelab versions of each.
There's still just too much flakiness with the Codegear drivers, us and our
customers have found them to be unstable in moderate to heavy usage.
Switching back to the Corelab version of each driver, our problems have all
went away.

It's very sad actually. One of the stated goals of the dbx4 rewrite was to
make the code standard between the various languages, allowing them to
improve and enhance them in a more timely manner. Unfortunately we just
can't use their drivers until they make them more stable.
--
Rich Werning
TIP Technologies, Inc.
Borland/Codegear has a longstanding problem with its Informix DBX drivers.
The drivers do not work in pooled, multi-threaded situations, raising an
error of "Connection name is use." I am trying to make the switch from D6
to D2007, but this is a showstopper. In D6, I switched to a driver from
Luxena, but it seems they are defunct, having no news on their site since
2006 and not responding to email. So if anyone knows how to work around
this, that would be great.
Alternatively, if anyone has a simple demo of multi-threaded database
access they would being willing to share, I might be able to use it to
demonstrate the problem in a support case. The problem arises in my app
which is large and uses RemObjects to manage the connection pool, so it's
not feasible to derive a test case from it.
Thanks,
Steve Pietrykoski
Loading...