Is there a way, for reads only, to have LLBLGen open and close a new connection from the Pool?

Hi David,

Please elaborate more on what you need and the specifics of your scenario, version, code, etc. ( http://www.llblgen.com/TinyForum/Messages.aspx?ThreadID=7725 ).

If you want to keep a connection open for certain operations, please see Connection Control.

The scenario is LLBLGen Pro 5.2.3 release 9/20.

Thank you for the link to the connection control under Adapter code generation.

Is there a way to keep to connection open using Self-Servicing?

The issue I am trying to address is similar to the one described under 'connection control' where a fetch command might be taken place under lazy loading while some save commands are incomplete causing the active reader to timeout because its connection closed.

The way I have been addressing this is by carefully controlling when the fetches occur.

Is there a way to keep to connection open using Self-Servicing?

That's exclusive to Adapter.

Please check this thread: http://www.llblgen.com/TinyForum/Messages.aspx?ThreadID=3793

How does the Adapter model handle lazy loading?

David wrote:

How does the Adapter model handle lazy loading?

There is no lazy-loading. In Adapter you pre-fetch the navigators instead of use y some ideas. For this you should use PrefetchPaths.

David wrote:

The scenario is LLBLGen Pro 5.2.3 release 9/20.

Thank you for the link to the connection control under Adapter code generation.

Is there a way to keep to connection open using Self-Servicing?

The issue I am trying to address is similar to the one described under 'connection control' where a fetch command might be taken place under lazy loading while some save commands are incomplete causing the active reader to timeout because its connection closed.

The way I have been addressing this is by carefully controlling when the fetches occur.

Create a Transaction, then do everything inside that Transaction: saves and fetches. They'll use the connection of the Transaction. (so first add the entity/collection to the transaction object, then call the methods which perform the work).

Connection pooling is transparent: it's been handled by the ADO.NET provider.

I'd look into whether you can get rid of the lazy loading and use e.g. prefetch paths. Lazy loading is something that looks nice, but in general will likely cause more problems than it's worth.

Create a Transaction, then do everything inside that Transaction: saves and fetches. They'll use the connection of the Transaction. (so first add the entity/collection to the transaction object, then call the methods which perform the work).

Oh, no doubt I missed adding the collection to the Transaction when fetching. Thanks!

Will this work with Self-Servicing?

When using a Prefetch Path, will the fetch of a related entity, not explicitly added to the transaction, not conflict with the Transaction?

Also, what happens with sub classes in which case the fetch is on the sub class and the inherited entity is not explicitly added to the Transaction?

Last but not least, Cheers to you guys! Thank you for the best support! I have yet to witness a software vendor with such dedication.

David wrote:

Will this work with Self-Servicing?

Sure. More info...

David wrote:

When using a Prefetch Path, will the fetch of a related entity, not explicitly added to the transaction, not conflict with the Transaction?

It shouldn't.

David wrote:

Also, what happens with sub classes in which case the fetch is on the sub class and the inherited entity is not explicitly added to the Transaction?

A transaction is not about entities but about the work you execute between the start and the commit. So the queries that will be executed when you are in inheritance include the parent table, so yes, the parent table it's included.

David wrote:

Last but not least, Cheers to you guys! Thank you for the best support! I have yet to witness a software vendor with such dedication.

Thanks David for your feedback and kind words. We hope you continue to enjoy the product and the support.