Thanks for the reply. Sorry I'm getting back to this late.
You mention that a detached object is temporarily attached for DB
operations. Can you give an example of a circumstance when this would
happen. I can't find any mention of re-attachment in the
documentation or code. From what I understand of NH, the only time an
object needs to perform DB operations is in a lazy scenario. And as
you mentioned, these just throw exceptions instead of attempting a re-
attach.
I seem to be able to use detached objects with lazy loading OK. I
just re-attach them to a session when I access something that may not
yet be hydrated. It would be nice if AR did this automatically
though. This is the method I wrote to do this:
public void Reattach() {
if (!holder.ThreadScopeInfo.HasInitializedScope)
throw new Exception("Cannot reattach AR object. No
open Scope.");
holder.CreateSession(typeof(T)).Lock(this,
NHibernate.LockMode.None);
}
The only problem with it is that it will throw an exception if the
object is already attached to a session. That is why I asked about
detecting if an object is currently attached to a session. I would
like to add a check before I attempt the re-attachment. But looking
deeper into NH, I don't think it is currently possible. It looks like
the proxy infrastructure is a little too transparent. You are unable
to ask this sort of meta-questions about NH objects.
If anyone is interested in my project:
I will be going with AR for my project. The maturity, performance and
features of NH coupled with the ease of use of AR make it a pretty
easy choice. There are definitely some warts however, neither project
was designed for the peculiarities of GUI use. I guess the desktop
jockeys are not as cool as the web dudes anymore.
As I mentioned before, my primary concern is the display of a large
tree structure in a list view which supports data virtualization. I
have decided to simply use detached objects for this. There should
not be any lazy loading issues with this particular implementation.
The data virtualization is handled by light-weight proxy objects that
know the identity of the AR object that they wrap. Once the proxy
objects are generated there will be no need to walk the tree.
So, the only issue is stale detached objects. To solve this, I keep a
list of currently displayed objects and re-load them when required.
The OnUpdate hook makes this relatively easy. No other process will
access this DB, so only local mods need to be accounted for.
This is not exactly ideal in my mind though.
So far, there are two additions I could use to AR and NH:
Automatic handling of re-attaching detached objects for lazy
operations. I can understand why AR does not do this. It looks like
it would require changes to NH, and custom implementations of the
collection proxies.
The option of a different first level cache. For web applications,
the build up and tare down of the sessions and their cache must be as
fast as possible and take as few resources as possible.
But in a GUI app I am willing to trade resources and speed for
additional management features. These features would include:
* Setting cache size and age targets.
* Monitoring object references.
* Auto-eviction of old and unused objects.
* Recovery from failed sessions.
Once I get more familiar with the code base, I may try to put some of
these pieces in place...
-Dan
On Jun 4, 7:31 am, Markus Zywitza <[email protected]> wrote:
> Inline:
>
> Dan Jasek <[email protected]>:
>
> > Is there a hook I can connect to to detect when a session has failed?
>
> If you are using IConversation, then it has an extension point for it as
> shown in the docs.
>
> > 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.
>
> Depends. Without conversations or scopes,every AR object is always detached
> and will be only temporarily attached for DB operations. Those detached
> objects however don't support lazy initialisation. You can however use a
> non-lazy-class for detached operations and a lazy class for attached
> operations that map to the same table.
>
> 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...
>
> Not if you need lazy-loading and you will need it when you have a single web
> of objects. See above for reasons.
>
> 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?
>
> No, but you might want to ask that question at the nh-users list.
>
> -Markus
--
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.
