Number of connections

Posts   
 
    
wvnoort
User
Posts: 96
Joined: 06-Jan-2005
# Posted on: 10-Mar-2005 09:56:38   

Hi all,

I just wrote a manager class that contains some application management functions like retrieving settings and distributing and archiving reports. The methods on this class are called from other manager classes. Everything works as expected, only i am unsure how it will behave on a large scale (as development progresses and in production).

As an example:

the ProjectManager class includes a method to import the budget from an external file. The actual budget entities created depends on some parameter.


bool includeTextLines = AppManager.ParameterValue(Parameter.IncludeTextLines);
...
if (includeTextLines)
{
   BudgetEntity budget = new BudgetEntity();
   ...
   budget.Description = ... text from import file ...
   ...
   adapter.Save(budget);
}

The actual value of the parameter to use depends on two entities. Fetching these is done in the ParameterValue method of the AppManager class. Now i have a uniform manner of retrieving a parameter setting with a single line of code.

The part where i am uneasy about is the fetching of the entities within the ParameterValue method. For each call it creates a new adapter, and as a result a new connection. I will be making this call a lot of times from the application.

Any comment is welcome

Otis avatar
Otis
LLBLGen Pro Team
Posts: 39933
Joined: 17-Aug-2003
# Posted on: 10-Mar-2005 12:24:47   

I think, if you have to optimize this routine, I'd first try to fetch all parameter value entities you have to fetch for the batch and store them in a hashtable, with their PK as the key, so you can fetch them in 1 query, and then in your AppManager index into that hashtable.

This prevents you from performing roundtrips to the db a lot of times, for tiny pieces of information at a time. The thing that could be a problem is how to determine which parameter value entities to fetch. (I'm not sure how much there are, if there are a dozen or so, that's not a problem, but if there are hundreds of thousands to fetch, it might still be more efficient to simply go to the database every time, or batch 5 or 10 budget entity creations to save roundtrips.

You can also build the hashtable on the fly: when AppManager fetches parameter value entities, it first checks if it doesn't already has one in a hashtable. In 1.0.2004.2 (now in beta) I've added a Context cache for this, which can save you roundtrips to the db in single entity fetches this way.

Frans Bouma | Lead developer LLBLGen Pro
wvnoort
User
Posts: 96
Joined: 06-Jan-2005
# Posted on: 10-Mar-2005 13:43:04   

Otis wrote:

In 1.0.2004.2 (now in beta) I've added a Context cache for this, which can save you roundtrips to the db in single entity fetches this way.

I just said to one of the other developers that it would be nice to have some context object available. You seem to know what people want ahead of time...

I want to take the example a bit further. Suppose I want to persist some changes to the database in the called method. Will this context cache enable me to use the same transaction as the one in the calling method?

Otis avatar
Otis
LLBLGen Pro Team
Posts: 39933
Joined: 17-Aug-2003
# Posted on: 10-Mar-2005 23:23:03   

wvnoort wrote:

Otis wrote:

In 1.0.2004.2 (now in beta) I've added a Context cache for this, which can save you roundtrips to the db in single entity fetches this way.

I just said to one of the other developers that it would be nice to have some context object available. You seem to know what people want ahead of time...

sunglasses

I want to take the example a bit further. Suppose I want to persist some changes to the database in the called method. Will this context cache enable me to use the same transaction as the one in the calling method?

The context simply holds references to entity objects. So if these get saved, those references don't change, though you're able to save them in any transaction you'd like. There is no awareness of a connection in the context, it just holds references to entities.

Frans Bouma | Lead developer LLBLGen Pro