I have been working on some testing code, ramping up on LLBLGen. I use the adapter templates. I am using the 2005 beta extended entity templates.

I am noticing that the first time the DataAccessAdapter is instantiated, there is a 1 to 2 second wait, but even if it is disposed in a using statement, the next time it is called is very quick as long as the test application has continued running. As soon as I stop the test app and re-run it, there is that delay on the first call.

The code that I am observing this in looks like and the delay is on the bolded line:

EntityCollection content = new EntityCollection(new MyContentEntityFactory());

        try
        {

            **using( DataAccessAdapter odapt = new DataAccessAdapter())**
            {

                IRelationPredicateBucket bucket = new RelationPredicateBucket();

                odapt.FetchEntityCollection(content,bucket);    

                return content;

            }
        }

I thought maybe that it is the result of the database connection being created on the first call but connection caching for later calls resulting is the quick latter access times. I created an SQLConnection to the same SQL Server 2000 database through code and it was almost instantaneous, the first time I call it.

For Windows Apps, I can see the ability to cache or keep the dataaccessadapter object aound and re-used throughout a form, or use case.

But what about web apps? Are people using LLBLGen for web apps where each request is going to create and tear down the DataAccessAdapter object? Does it always incur this 1-2 second delay or will it only be slow for the 1st access by the IIS worker thread process, but all subsequent requests will be quick? Is this an aberration of my environment.?

Hoping someone might be able to shed some light on this observation.

Thanks.

Can1

I am noticing that the first time the DataAccessAdapter is instantiated, there is a 1 to 2 second wait

If you are on XP, win2k upwards, my understanding is that connection pooling kicks in. Hence the reason you are seeing this only the first delay first time.

for more infor on pooling see

http://msdn.microsoft.com/library/default.asp?url=/library/en-us/cpguide/html/cpconConnectionPoolingForSQLServerNETDataProvider.asp

But what about web apps? Are people using LLBLGen for web apps where each request is going to create and tear down the DataAccessAdapter object? Does it always incur this 1-2 second delay or will it only be slow for the 1st access by the IIS worker thread process, but all subsequent requests will be quick?

I use Oracle and therefore ODP.NET in my web apps and I see the first connection is slow, but subsequent one's are faster. SQL Server has the same behaviour. In IIS 3, pooling is 'false' by default, but IIS 4 onwards, pooling is 'on' by default. Here is some interesting reading on this subject .

http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnmdac/html/pooling2.asp

The following arcticle 'talks' about managing these sessions

http://msdn.microsoft.com/SQL/default.aspx?pull=/library/en-us/dnbda/html/daag.asp#daag_managingdatabaseconnections

Is this an aberration of my environment.?

No I think you are fine, however, if you have any more queries, please 'come back'.

Hope you find this useful.

I was hoping that the delay is just a function of establishing the connection, and not an LLBLGen internals issue. This then should be handled without issue by the connection pooling features of the .NET data provider. I will run some load tests under .ASPX to confirm.

Thanks again.

The first connection is typically slow because of: 1) the JIT starts jitting the ado.net provider used for the database (and additional code used by that provider) 2) assemblies have to be loaded into memory 3) connection to the db has to be made, which is initially slow due to network latency and the server has to be waken up perhaps.

after that, it's fast. Not only because of connection pooling, but also because some things like jitting and assembly loading aren't necessary anymore, because they're already done .