Is any cleanup necessary when using LinqMetaData on a SelfServicing model without a transaction (we created LinqMetaData with the default constructor)? There's no Dispose or Close method, and there is no accompanying DataAccessAdapter to dispose as is the case in Adapter mode.

If I create an entity or modify an entity loaded from LinqMetaData and try to save it, are any transactions being auto-magically created under the covers (when calling CommonEntityBase.Save)?

We're seeing some issues where our web app (which uses SelfServicing) is throwing SQL timeout exceptions (only on the production server, so it's hard to debug), and it seems likely we must be doing something wrong with our use of LLBLGen.

Is any cleanup necessary when using LinqMetaData on a SelfServicing model without a transaction (we created LinqMetaData with the default constructor)? There's no Dispose or Close method, and there is no accompanying DataAccessAdapter to dispose as is the case in Adapter mode.

In the adapter scenario the adapter needs to dispose the connection object, and it does so no dispose call is needed. It by default closes a connection after an action, which gives the underlying connection object back to the pool. The adapter will dispose the active connection object when it closes it. For SelfServicing is not that different, a connection is open and closed for each call, but remember that the LinqMetaData is not responsible of disposing the connection. LinqMetaData is a class for the construction of Linq queries.

If I create an entity or modify an entity loaded from LinqMetaData and try to save it, are any transactions being auto-magically created under the covers (when calling CommonEntityBase.Save)?

In that case the transaction is used only for the .Save action. You can include your Linq fetch though:

Transaction trans = new Transaction(IsolationLevel.ReadCommitted, "SSTest");
LinqMetaData metaData = new LinqMetaData(trans);
var q = (from c in metaData.Customer select c).ToList();

CustomerEntity customerToSave = q[0];
//.... some changes
trans.Add(customerToSave);
customer.Save();

...
trans.Commit();

We're seeing some issues where our web app (which uses SelfServicing) is throwing SQL timeout exceptions (only on the production server, so it's hard to debug), and it seems likely we must be doing something wrong with our use of LLBLGen.

Would be good to enable some tracing or try to reproduce it in your development environment.

What LLBLGen version and runtime library version are you using btw? (http://www.llblgen.com/TinyForum/Messages.aspx?ThreadID=7722)

LLBLGen 3.1 SelfServicing, .NET 4.0, SQL Server 2008

It's good to know that LLBLGen handles all of that internally after each call. Since we were just constructing LinqMetaData with the default constructor, I wasn't sure how the connections were being handled under the covers. Given that the production server was getting timeout exceptions, I thought perhaps there was a chance connections might be left open until some timeout period elapsed or a finalizer cleaned them up.

It turned out that the problem seemed to be that permissions weren't set properly on the server for a new table that was added. Once the admin fixed that last night, users stopped getting the timeout exceptions. I'm guessing that SQL Server has some logic to time out connections when a user keeps trying to access something they don't have permission for, but I can't seem to find a definitive answer for that in my brief google searches this morning.

Thanks for the quick answer.