Although I created the ScopedConversation for GUI support of AR, I had not the use of Conversation per Application Instance in mind.
The real benefit of conversation per form is that you can lazy load by form. Using it for keeping a large number of objects in 1st level cache is not good because when you have to restart it, those objects are gone and have to be reloaded. So what you should you do with your big list? Well, since you manage the contents of the list for yourself, you should use those objects for explicitly proxying the records. Load only partial data for the objects to display them and create objects that load the AR entities when needed. These proxies can keep conversations for managing the entities. When you can keep the objects separate, I would use a conversation per web of objects. However, when these are intermingled in only a single web of objects, you'll end up again with one single conversation. In this case, the large conversation should be read only, while loading objects for modification separate conversations which should be business transactionsto minimize the risk of modifying an objects simultanously in more than one conversation. A last consideration should be dropping AR and relational databases altogether. Your scenario sounds like a perfect fit for a graph database. Perhaps you want to look at InfoGrid or Neo4j, both have language-independent APIs (REST and RDF/OWL). If you decide for AR, I would be glad if you keep me informed about the project. -Markus 2010/5/28 Dan Jasek <[email protected]> > 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]<castle-project-users%[email protected]> > . > For more options, visit this group at > http://groups.google.com/group/castle-project-users?hl=en. > > -- 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.
