TRoPooledFactory : maximum pool size reached

i’ve created a new service
used pooledfactory with 1 instance preinitialized and pbCreateAdditional

now i create 20+ datamodules who all target the one table in this DA service, using a localdatable and a localdataadapter (using it in the same daserver so local)
this is done in a loop, so there is no threaded access to the pool
and yet it isn’t reusing the pool it seems?

i think the localdatatable.loadschema is the one to blame…

Hi,
if you set CacheSchema to True in LDA, will it solve this case?

localdataadapter does not have that property?

but not doing loadschema does not solve the issue…
don’t see the reason why it does not recycle the pool…

Can you create a simple testcase that reproduces this issue, pls?
you can send it directly to support@

mail on his way

error is raised because you have reached end of pooled connections:

uDACore.DAError(True,'Maximum pool size reached. Cannot create a new connection')
uDAConnectionManager.TDAConnectionManager.NewConnection('',True,'','')
DataAbstractService_Impl.TDataAbstractService.GetConnection

you can avoid his error if you set DAConnectionManager.PoolingEnabled to False or redesign your code.

but why doesn’t it recyle open connections?

in our main app pooling is also enabled and i never encountered this …
so i don’t see why i run out of connections here…

if i alter the demo project to use a remotedataadapter (using localchannel) then it just works…
so the issue must be with localdataadapter?

in your case, you have dropped LDA (=local data adapter) to TServerParamProxy so for each TServerParamProxy object, own DataService instance is created.
each DataService instance keeps own IDAConnection.

workaround: use one LDA per service and put it into server datamodule.

note: you have specified pbCreateAdditional in TROPooledClassFactory constructor so it created additional DataService instance at request

ah so the difference with remotedataadapter is that:

  • dataservice is reused (cause its a pooled one)
  • it does not hold on to a specific idaconnection
    right?
    so in fact a big difference between local and remotedatadapter?

but going furter, let’s say i have 15 services and i drop an localdataadapter on every one of them, and i pull in data on all 15, i will run out of connections also?

also if i preinitialize with 15 dataservice instances, those do not keep an connection reserved specifically for them ?

so i don’t get the mechanism … even if the local data adapter creates it’s own dataservice instance, why should it lock a connection?

you can release unneeded services after usage.
just assign LDA.ServiceInstance to nil. it will release service and release connection.

connection will be acquired once it will be used. each DataService locks connection. ofc, you can manually assign nil to Connection property and release it.

but putting the localdataadapter to the dataservice remedies the problem
and introduces a crash on closing the app cause the release of the localdataadapter does not find its service…
furthermore, since i’m now referencing the localdatadapter from the service, this seems kinda recipe for disaster?

i don’t see why the behaviour of a localdataadapter is different from a remote one…

if i do the same with remoteadapter using localchannel it works…
even if the localadapter holds an instance to the service i don’t see why it should block a connection…
i also don’t see why localadapter should keep an instance of the service for exclusive use? that way to many instances are created…?

unit DataService_Impl;
...
finalization
  UnRegisterClassFactory(fClassFactory);
  fClassFactory := nil;
end.

this code is executed before your TComputerIniFilesManager is cleared. it is reason for this error.

workaround: clear this object in FormClose/FormDestroy or similar event.

it keeps it for case when you should do several requests via LDA. it will give you a good performance.
after usage, just clear LDA.ServiceInstance

if you use this code, it will work similar to RDA:

function TServerParamProxy.LoadComputer: boolean;
begin
..
        LocalDataTable.Open;
        DALocalDataAdapter.ServiceInstance := nil;

another case: put LDA to server datamodule and all your TServerParamProxy.LocalDataTable should reference to to this LDA. it also give you performance and it will use one server instance and one connection for all requests.

<< another case: put LDA to server datamodule and all your TServerParamProxy.LocalDataTable should reference to to this LDA. it also give you performance and it will use one server instance and one connection for all requests.>>

i want to buidl on this one: since the dataservice is pooled and since it will be used to serve other tables also, how will it just use 1 server instance and 1 connection…
the proxy itself is wrapped in another pooled service which is called by several clients so it can write updates simultaneously…

i want to fully grasp this before running into troubles…

wait by ‘server datamodule’ you don’t mean putting the localdataadapter in the DataService datamodule right?

that makes more sence, but then i still have the issue that the calls to the proxy may be threaded, so i guess the localdataadapter can’t handle that or?