Lazy object session management - AR
3 views
Skip to first unread message
Dan Jasek
Aug 21, 2010, 12:32:18 AM8/21/10
to Castle Project Users
I have been looking into lazy loading and its session requirements.
I've come up with a solution for loading lazy objects outside of a
standard SessionScope. All that was needed was a custom ByteCode
where the Initialize method was wrapped in a little session management
code.
The code is here: http://gist.github.com/541691
The important bit is LazyInitializer.Initialize()
Unfortunately, this code requires that the original Initialize
function be virtual, which is not the case in the current release.
I added a request for this change to the NHibernate JIRA here:
http://216.121.112.228/browse/NH-2292
Hopefully it will not be too difficult to get this minor change
approved. If not, this strategy can still work by copying the entire
LazyInitializer implementation into the custom ByteCode.
I don't know too much about the internals of NH. I'm pretty much
poking at the dark with a stick here. This may not be bullet-proof,
but it works for the simple cases I have tried so far. I've done some
performance tests as well and this does not seem to degrade speed by
any appreciable amount.
This is only half the battle, however. It doesn't do anything for
lazy-load collections. That one is a bit more difficult, but a
similar strategy could be applied there as well. There are several
methods in AbstractPersistentCollection that would need to be
changed. And that class is the parent to a half dozen collection
classes.
I see two options. Either create a custom version of the entire
persistent collection infrastructure, or modify the current one to
inject the session verification strategy at run-time.
Creating a custom collection handler would be a pain in the ass, but
the current NH code already supports this. It looks like the ByteCode
provider can provide a custom CollectionTypeFactoryClass, though none
of them currently do.
Injecting the verification strategy would be much easier on my end.
But it would require a refactor of the entire collection proxy
complex. I don't know how easy it would be to get approved by the
guys over at NH.
Markus, or anyone else. Any comments or suggestions on this?
I've come up with a solution for loading lazy objects outside of a
standard SessionScope. All that was needed was a custom ByteCode
where the Initialize method was wrapped in a little session management
code.
The code is here: http://gist.github.com/541691
The important bit is LazyInitializer.Initialize()
Unfortunately, this code requires that the original Initialize
function be virtual, which is not the case in the current release.
I added a request for this change to the NHibernate JIRA here:
http://216.121.112.228/browse/NH-2292
Hopefully it will not be too difficult to get this minor change
approved. If not, this strategy can still work by copying the entire
LazyInitializer implementation into the custom ByteCode.
I don't know too much about the internals of NH. I'm pretty much
poking at the dark with a stick here. This may not be bullet-proof,
but it works for the simple cases I have tried so far. I've done some
performance tests as well and this does not seem to degrade speed by
any appreciable amount.
This is only half the battle, however. It doesn't do anything for
lazy-load collections. That one is a bit more difficult, but a
similar strategy could be applied there as well. There are several
methods in AbstractPersistentCollection that would need to be
changed. And that class is the parent to a half dozen collection
classes.
I see two options. Either create a custom version of the entire
persistent collection infrastructure, or modify the current one to
inject the session verification strategy at run-time.
Creating a custom collection handler would be a pain in the ass, but
the current NH code already supports this. It looks like the ByteCode
provider can provide a custom CollectionTypeFactoryClass, though none
of them currently do.
Injecting the verification strategy would be much easier on my end.
But it would require a refactor of the entire collection proxy
complex. I don't know how easy it would be to get approved by the
guys over at NH.
Markus, or anyone else. Any comments or suggestions on this?
Markus Zywitza
Aug 21, 2010, 2:56:33 AM8/21/10
to castle-pro...@googlegroups.com
Hi Dan
I had the same idea some time ago and experienced the same problems. In theory it is possible to create a custom bytecode provider and collection proxies to make lazy-loading work without SessionScope, yet it requires us to use a custom built NHibernate.
But back to the original idea: Why do you want to use AR without sessions? IConversation is an alternative to SessionScope that allows you to use a "Sessions-per-(whatever)"-pattern. Web applications can use the session-per-request-pattern without problems.
-Markus
I had the same idea some time ago and experienced the same problems. In theory it is possible to create a custom bytecode provider and collection proxies to make lazy-loading work without SessionScope, yet it requires us to use a custom built NHibernate.
But back to the original idea: Why do you want to use AR without sessions? IConversation is an alternative to SessionScope that allows you to use a "Sessions-per-(whatever)"-pattern. Web applications can use the session-per-request-pattern without problems.
-Markus
2010/8/21 Dan Jasek <dan...@jasek.org>
--
You received this message because you are subscribed to the Google Groups "Castle Project Users" group.
To post to this group, send email to castle-pro...@googlegroups.com.
To unsubscribe from this group, send email to castle-project-u...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/castle-project-users?hl=en.
Dan Jasek
Aug 21, 2010, 3:11:26 PM8/21/10
to Castle Project Users
I am not writing a web application. Many of my objects have an
arbitrary and long lifetime. Because of this, I am often working with
detached objects. IConversation won't work because the first level
cache will accumulate all objects I load, and my application design
does not provide an easy point where I can close and reset the
conversation. There are always a few objects in use. Additionally, a
failed session would be a major PITA to recover from if used a
IConversation based design.
The only pattern that I can see working is "session-per-application"
which is not recommended (for good reason).
Detached objects work fine, except for lazy proxies. For those, I
have to re-attach it to a session. Which means, just to access some
data on an object, I have to remember if it could be lazy and wrap the
access in session boilerplate. This is the sort of thing the
framework should be doing.
When I am reading/writing from a number of objects, I will use a
SessionScope for performance. But most of the time I am handling
event based user actions, the overhead of opening/closing a new
session for the single action is not really important. And it is much
easier than trying to manage a scope or conversation across multiple
event handlers and data bindings.
I think it is possible to implement this in a custom ByteCode that
works with the current version of NH. If I end up doing this, would
you be interested in adding it to AR?
-Dan
> > castle-project-u...@googlegroups.com<castle-project-users%2Bun subs...@googlegroups.com>
> > .
arbitrary and long lifetime. Because of this, I am often working with
detached objects. IConversation won't work because the first level
cache will accumulate all objects I load, and my application design
does not provide an easy point where I can close and reset the
conversation. There are always a few objects in use. Additionally, a
failed session would be a major PITA to recover from if used a
IConversation based design.
The only pattern that I can see working is "session-per-application"
which is not recommended (for good reason).
Detached objects work fine, except for lazy proxies. For those, I
have to re-attach it to a session. Which means, just to access some
data on an object, I have to remember if it could be lazy and wrap the
access in session boilerplate. This is the sort of thing the
framework should be doing.
When I am reading/writing from a number of objects, I will use a
SessionScope for performance. But most of the time I am handling
event based user actions, the overhead of opening/closing a new
session for the single action is not really important. And it is much
easier than trying to manage a scope or conversation across multiple
event handlers and data bindings.
I think it is possible to implement this in a custom ByteCode that
works with the current version of NH. If I end up doing this, would
you be interested in adding it to AR?
-Dan
> > .
Markus Zywitza
Aug 22, 2010, 4:19:41 AM8/22/10
to castle-pro...@googlegroups.com
Of course I'm interested.
-Markus
-Markus
2010/8/21 Dan Jasek <dan...@jasek.org>
To unsubscribe from this group, send email to castle-project-u...@googlegroups.com.
Reply all
Reply to author
Forward
0 new messages