Embedded Hibernate service - TODO
Publishing a technical discussion for a more thorough peer review:
> From: Steve Ebersole
> Sent: Monday, August 09, 2004 6:31 PM
> To: Alexey Loubyansky; 'Christian Bauer'; 'Gavin King'
> Cc: Ivelin Ivanov
> Subject: RE: jboss - hibernate
>
> #4 would add "CMT-like" capability strictly around a
> Hibernate session. Say I'm not using JTA but I want
> automatic transaction handling (of the Hibernate Transaction
> object, that is). Probably rare, I know, given the
> environment, but definitely possible. This would use a
> pattern similar to the HibernateUtil stuff Gavin and
> Christian developed for the book.
>
> #6 would be the ability to retrieve a different session other
> than the one currently bound to the SessionContext for a
> given jndi name. Consider a Hibernate Interceptor. Most
> calls (the ones where you'd most like to do it, at any rate)
> into the Interceptor expressly prohibit any calls back into
> the session. The typical recommendation around this is to
> generate a new session on the same connection as the original
> session (something like
> SessionFactory.openSession(originalSession.connection())).
> This would be a way for those types of calls to happen in the
> same fashion as the others (something like
> SsessionContext.getUnmanagedSession()).
>
>
> -----Original Message-----
> From: Alexey Loubyansky
> Sent: Monday, August 09, 2004 10:15 AM
> To: Steve Ebersole; 'Christian Bauer'; 'Gavin King'
> Cc: Ivelin Ivanov
> Subject: RE: jboss - hibernate
>
> Hi Steve,
>
> 1 is definitely needed. Could you please clarify 4 and 6?
>
> Thanks!
>
> alex
>
> > -----Original Message-----
> > From: Steve Ebersole
> > Sent: Monday, August 09, 2004 6:03 PM
> > To: Christian Bauer; 'Gavin King'; Alexey Loubyansky
> > Cc: Ivelin Ivanov
> > Subject: jboss - hibernate
> >
> > Some thoughts on jboss - hibernate integration moving forward:
> >
> > 1) There is no lifecycle listening between the
> interceptors/context
> >and the mbean. This means the mbean could be stopped and
> the session
> >context stuff would fail with misleading errors. The
> registration of
> >a jndi name with the SessionContext should also spawn a jmx
> listener
> >on the s mbean for its lifecycle events, so that we can
> appropriately
> >cleanup the context when the mbean stops.
> >
> > 2) The deployer uses the Hibernate method
> > Configuration.addJar() to parse the deployment for mapping files.
> > This method has been deprecated. We should either reconsider that
> > deprecation, or re-implement that functionality in the deployer
> > itself.
> >
> > 3) Need to add auto-flushing capability to the interceptors.
> > This should be configurable, with 3 options: NEVER, ALWAYS (i.e.,
> > after each intercepted method), BINDER (i.e., after
> intercepted call
> > which resulted in session binding). Maybe there are better names.
> >
> > 4) Should we add auto-transaction capability similar to #3 above?
> > This would really only be pertinent for thread scoped session
> > interception. This could be handled by the current
> interceptors, or
> > as a separately applied interceptor.
> >
> > 5) Consider additional configuration capabilities for the mbean,
> > similar to the discussion for the generic hibernate jmx stuff.
> >
> > 6) Add the ability to retrieve an "unmanaged" session from the
> > SessionContext. This probably makes the most sense as a
> new session
> > on the same connection as the existing "managed"
> > session. This allows app code to get all sessions in a similar
> > fashion.
> >
> > 7) A clean way to attach Hibernate Interceptors.
> >
> >
> > Anyone have any additional desires for this stuff moving
> forward? Or
> > agree/disagree with anything above?