Thanks for the reply. I would not have a problem reloading the objects when necessary. There will only ever be 20-40 objects displayed at a time, and I already need to maintain a list of them for the virtualization layer. Is there a hook I can connect to to detect when a session has failed? Also, is it possible to determine if an AR object is attached to an active session or not? I looked through the documentation but didn't see a way.
The proxy object concept is a good call. I plan on using it in my data virtualization layer. The tree I am displaying is flattened into an ordered list and stored as a series of lightweight proxy objects. When a node needs to be displayed, the proxy is expanded with the AR object and the view is built. Unfortunately, my data is a single large tree so a conversation per web won't work. Using conversation per modification could work. If I did this, I don't think there would be any advantage to keeping the read-only display objects in a conversation (I don't need to traverse the web at this point). I could just leave them as detached... I would like to avoid this method because I will need to keep track of the records I modify and reload any associated display objects. Though, I suppose that won't be any more difficult than keeping track of the objects I touch and evicting them when I'm done. Maybe I could periodically clean the cache myself. It looks like NHibernate keeps the cache internal, however. Do you know of a way to get to it? I suppose I could restart the conversation and reload the active objects. But that seems like a waste. Conversation per web won't work for me as my datasource is a single large tree structure. I have been looking at the NoSQL camp, but I think I will need to stick to a relational database for this project. I like AR for a lot of reasons, but this session issue may end up driving me to something else. I'll let you know what I end up doing. Thanks, -Dan On May 28, 3:06 pm, Markus Zywitza <[email protected]> wrote: > 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%2Bun > > [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.
