support for long hibernate sessions
Status: Abandoned
Brought to you by:
jfpoilpret
Menu
▾
▴
#4 support for long hibernate sessions
I use the Hibernate long-session pattern for most of my
apps.
To do that, I've implemented an additional
service-model that relies on some
persistence service storing services somewhere in
between requests
(typically backed by an http session).
Now for the question: would it be easily possible and
desirable to integrate
such a feature in hivetranse? After a first glimpse at
the code this seems
not too difficult to me. hivelock already has a similar
service model called
"user". The main point would be to make
HibernateTransactionService
compatible with this service model (adding additional
lifecycle-support for
disconnecting/reconnecting sessions.
Also, I'm wondering how deeply the equation (TA =
Hib-Session) is built into
hivetranse. After all, long sessions can be
committed/flushed without ending
it.
Marcus
Logged In: YES
user_id=815191
Hi Marcus,
originally I did not think about long sessions in hivetranse, do
you have a practical use-case where this is useful?
About the possibility to integrate it into hivetranse, it is hard to
say for now:
- making the sevice model configurable seems easy (through a
symbol defined in FactoryDefaults and possibly overloaded in
ApplicationDefaults)
- however, as you mentioned, the TransactionService must
implement the right lifecycle interface to be able to close the
session at a proper time, which is possible only if the number of
interfaces is predefined and never changes (a brand-new
servicemodel might introduce new lifecycle interfaces). In the
case of hivelock "user" servicemodel, that's no problem since it
reuses hivemind's Discardable lifecycle interface which is
already implemented by HibernateTransactionService.
As you ask, is it desirable? For that question I wonder. For the
moment, I would say no, but I prefer to have a good use case on
hand to see if it would make sense in hivetranse.
About the equation TA = Session, I am not sure it would be easy
to change it in hivetranse. However, you have to note that with
the "deferSessionClose" feature, transactions are committed (or
rolled back) without closing the session.
Finally, about the "long session" pattern itself, you have to be
aware that such a pattern would not make your system very
scalable.
Cheers
Jean-Francois
Logged In: YES
user_id=1286323
Hi Jean-Francois,
thanks for answering. As for use cases - any application for
which server-side state containing persistent domain objects
is acceptable and desirable is a use case. Compared to the
favoured detached object pattern it gives you the (imo big)
advantage of getting rid of LazyInitialisation- and
DuplicateObject-Exceptions, and, even more important, avoids
the ad hoc code working around those, which, essentially,
introduces an evil coupling of dialog and persistence layer.
See the book by Bauer&King or
http://marcus-schulte.blogspot.com/2005/04/if-you-cant-hide-it-below-hide-it.html
if you're interested in more advocacy of this view.
Each of our new apps will use this pattern (if it uses
hibernate at all).
I'm also wondering why you're concerned about scalability
when using long sessions? I must admit that our apps have
only some 100 concurrent users at most, but I don't see any
problem, in principle, to scale up.
regards,
Marcus
Logged In: YES
user_id=815191
Hi Marcus,
I just took a look at your blog and at the Hibernate page that talks
about various patterns for Hibernate TA/Session management (I
had already taken a look at that page but that was long ago).
I suppose the "long session pattern" you talk about is what Gavin
calls "session-per-application-transaction", right?
When I talked about scalability, I did not think about the
possibility to disconnect/reconnect JDBC Connections to
Sessions, that was my first concern here. Still, storing the
Session (Hibernate) in the Session (Http!) could still infer the
following issues:
- clustering
- potential huge amount of memory (cache of Sessions)
Currently, hivetranse uses the "session-per-transaction" model
(kinda).
First of all, with the current hivetranse version, although you do
not have the "session-per-application-transaction" model, you still
have the possibility to use the "open session in view" feature that
would remove most of the LazyInitializationException that people
often get with Hibernate. This does not solve all the problem but
that's already something that is possible now, with no new
hivetranse release.
From a general viewpoint, I don't think the "session-per-
application-transaction" model would be very difficult to
implement in hivetranse.
However there are some points left unclear, or some decisions to
make about integrating this feature. I would like to have your
feedback (you and other readers of the forum) about these.
1- Should the "session-per-application-transaction" model be
mixable with the current hivetranse "session-per-transaction"
model in the same application?
If the answer is yes, then I do not see how the developer could
configure that choice (because hivetranse can manage many
sessions in the same "request/response" according to
transaction demarcation settings).
2- How can you decide to close a Session at the middle of your
application?
As you said in your blog, you have to "request a fresh hibernate
session at some sensible point".
The problem here is to avoid introducing a specific API for that!
Is it foreseeable to never request a fresh hibernate session, but
rather let the developer just call clear() on the current session
when needed?
3- How do you solve the "zombie" Sessions after the user
disconnects in a dirty way (no proper logout, just close the
browser window)? You have to wait until http session timeout
don't you?
This may be an issue if many users use your application this
way (let alone hackers...)
After those discussions are closed, I will see what a reasonable
schedule could be for a new release. Please note however that
currently I have several on-going (and urgent) works on
hivetranse:
- SQLException mapping (ala Spring but less intrusive, no need
for "spring templates")
=> this will lead to a 0.4.2 hivetranse version (including Hibernate
Interceptor support)
- HiveMind 1.1 support (I did not start anything on that point and
I am afraid it may not be so easy as it could seem)
=> planned 0.5.0 version of the HiveMind Utilities
- Hibernate 3 support (I did not start anything either on that point,
I dunno what I should expect for the difficulty of porting)
Cheers
Jean-Francois
Logged In: YES
user_id=1286323
Hi Jean-Francois,
regarding the issues/questions you brought up:
ad 1.: No, I don't see any need for mixing, at least not for the same
SessionFactory. For different SessionFactories/database I can imagine
scenarios where it would be nice but even this would be a rare case for us.
ad 2.&3: I think of a session as the pool of those persistent domain
objects the user works with. Whether you keep these objects in your
session detached or whether you keep them connected to session - at
some point they have to be thrown away.
ad2: calling session.close() is perfect, no need to explicitly call for a new
session.
ad3: Cleanup is possible using HttpSessionBindingListener. How to
configure the Session to cope with "rogue users" is more an issue for the
web-framework, I think. If you use tapestry, you could set a very short
session-timeout and use the xtiles component to keep the session alife
while one of its pages is opened in a browser.
I see that there are some arguably more important tasks for hivetranse,
especially 1.1-support. In September I think, I'll have some spare-time I
could offer to help out, if you'd like that.
regards,
Marcus
Logged In: YES
user_id=815191
Marcus,
thank you for your feedback and for your help proposal. Any
help is always appreciated.
For the next month I think I will focus on HM1.1 support (and
maybe on Hibernate3), in addition to enhancements to other
modules of HiveMind Utilities (I have just finished SQLException
mapping, but no HibernateException-mapping yet).
If during this summer I have time, I will have a look at long
session support, else I will wait for your help in September;-)
Cheers
Jean-Francois