This thread looks to be a little on the old side and therefore may no longer be relevant. Please see if there is a newer thread on the subject and ensure you're using the most recent build of any software if your question regards a particular product.
This thread has been locked and is no longer accepting new posts, if you have a question regarding this topic please email us at support@mindscape.co.nz
|
Hello, I've been doing some research into optimising LINQ performance and and wondering if LightSpeed could handle persistent context's? 1 - ie - Is there any performance advantage from keeping a Thread Specific Context open for the life of the application? It seems wasteful to dispose of Contexts so quickly. 2 -When the Context is disposed of - does lightspeed drop the MySQL/DB connection? Or keep it open for future queries? 3 - Does LightSpeed support compiled queries? (LINQ concept - I think it applies here for speed improvements) Thank you! Jared |
|
|
|
|
Hello Jared, 1. We advise against keeping a context (unit of work) open for the lifetime of the application because this can be brittle with regard to connection or network errors. Because the unit of work represents a business transaction it should be short-lived if possible. Also, in our implementation the unit of work also supplies the identity map (first level cache), so additional work is required if you need to force a refresh. Units of work are relatively cheap so creating and disposing them isn't a huge deal. (I realise connections are relatively expensive but see the next point.) Note by the way that a LightSpeedContext object *can* and *should* be kept open for the lifetime of the application. The LightSpeedContext is just a collection of configuration information, with no data or connectivity state, so there is no point reloading or recreating it. 2. Yes, the connection is closed when the unit of work is disposed. However, the MySQL driver will (unless told otherwise) keep the connection available in the connection pool so it can be reused for future queries. So connection usage should be pretty efficient even though you are frequently creating and disposing units of work (and, by implication, their underlying connection objects). 3. As mentioned on your other thread, we don't support compiled queries in 3.0, but we know a lot of people are keen to see them and they are definitely on the wishlist. |
|
|
|
