I am working on a WPF client application backed by Active Record, but I have run into problems with the sessions. I believe I have a solution, but I'm not sure if it is a good idea or not.
Here is the background: The heart of this WPF application is a large List that displays a collection of entities served up by AR. The collection can be very large (10,000 records) and the entities are rather complex (a network of inner-relationships). To display the collection I have setup a data virtualization infrastructure so that only the records needed to be displayed will be loaded from the database. To make this work, I have to explicitly handle the lifecycle of the objects. This all works great on the UI side. However, on the AR side, I have hit a stumbling block. As these objects are rather complex, I want to keep them attached to a session so the inter-relationships remain wired up properly. The problem is that this List will be displayed for the entire lifecycle of the application. And everything I have read says that keeping a SessionScope open for that long is a very bad thing. I have not found a detailed explanation of why it is bad, however. >From my research it looks like there are three primary issues: 1) NHibernate sessions are not thread-safe. In fact, it looks like the SessionScope has thread affinity that is enforced by the ScopeInfo. 2) The first level cache will fill up. The cache was not designed to be long running and will not properly clear old records on it's own. And with my large dataset, this would be a problem. 3) Your object may be modified behind your back. (3) is not an issue in this application. I am already monitoring the lifecycle of my objects through the data virtualization layer. It will not be an issue to evict the objects as I tare them down. This should fix issue (2). To fix (1) I simply need to marshal any AR call to a single thread. I believe can do that through a System.Windows.Threading.Dispatcher without much issue. Also, wandering through the AR source I stumbled on the ScopedConversation. The only reference i could find for it was the excellent article here : http://using.castleproject.org/display/AR/Using+the+Conversation+Pattern But it looks like it is exactly what I need to maintain my sessions across the application lifecycle. It even has a Restart function in case I find the need to periodically rebuild the connection. So, I plan on using a ScopedConversation to keep a session open for the lifecycle of the application. I will ensure all AR calls are run on a single thread and I will handle object eviction myself. Is this a sound design? Are there additional pitfalls I may run into? Or is this all just a bad idea? Thanks, -Dan -- You received this message because you are subscribed to the Google Groups "Castle Project Users" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/castle-project-users?hl=en.
