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
|
I have developed a MS MVC Web application using mindscape 2.0 and mysql on a IIS 7.0. I am using the strategy of PerRequest connections, and at start storing essetiel entity objects; like my shoppingbasket and customer in http session. At first I write, because after setting the site into public production my worker process in IIS went memory berzerk to around 1,3GB and my IIS sort of died due to memory swapping. The memory grew from a fresh thread to around 500MB in a minute. I tried to recycle my worker process at 500MB, that helped but session data was killed. When I tried to move session out of 'In-process' to a state-server for the IIS. Site did not chrash anymore and simple none entity objects did not give any problems, but immedeatly after adding something to a basket the state-server grewing in memory. I have now removed my entity objects away from the session, and only storing ids and none-stored enity objects, like a customer not ready for storing. So problem fixed, but why can I not store enity objects on the session objects? I guess there must be some sort of reference to a core mindscape pool object that takes every thing along on the sesion, and can I perhaps detach and entiy for session storage purpose, and attach it a new request is handled?
|
|
|
|
|
What you're doing now is exactly what we recommend (and what we do in our own LightSpeed-based sites): store an ID, and reload when required. Storing entities in session state is possible (we have customers who do this) problematic because entities have an affinity to a unit of work and the unit of work can *NOT* be stored in session state. So in this case you need to manage entities very carefully, attaching them rather than querying (because querying will materialise a new entity from the database rather than looking in session state), handling the potential for concurrent requests, etc. I am guessing that the memory explosion might be because it is materialising new entity instances on every request but still storing all these obsolete instances in session state -- I'm not sure, though, as we haven't seen this before that I know of. You can also use caching: see JD's post http://www.mindscape.co.nz/blog/index.php/2009/11/05/whats-the-deal-with-lightspeed-caching/ - this is safer than session state because LightSpeed manages it for you. The cache itself is of course shared, but you can combine this with the "IDs in session state" idea to reduce database load while remaining session-safe and keeping memory usage under control. |
|
|
|
