Hi Peter,
ah, ok, right now I do the following:
- define a "Manager"-Service, which gets a Hibernate-Session-Proxy
injected. This Manager has typical DAO-methods like findXyz, additionally it
implements the following interface
public interface Manager {
void persistEntity( ExtranetEntity entity );
void deleteEntity( ExtranetEntity entity );
void beginTransaction();
void commit();
void rollback();
}
The Manager-Impls have two fields, "session" and "transaction" to do their
job. You 're right, my Hibernate session lives as long as the corresponding
user's session and that's fine for my apps (typically about 200 parallel
sessions per app). The big advantage of this is: it makes sure that you
never have any persistent domain objects in your session whose hibernate
session is closed. If you want to close the Session yourself be sure to
throw away the objects belonging to it.
Now, to do what you want, you could just add "clearSession" to the above
interface and implement it with "session.close()". Then change the method
SessionProxy.invoke() to check for a closed session and get a new one, if
it's closed, like that:
//...
public Object invoke( Object proxy, Method method, Object[] args ) throws
Throwable {
if ( ! session.isOpen() ) {
session =getSessionFactory().openSession();
}
if (method.getDeclaringClass().equals(Session.class))
return method.invoke( session, args );
//...
best regards,
Marcus
> -----Original Message-----
> From: Peter Ertl [mailto:[EMAIL PROTECTED]
> Sent: Friday, September 30, 2005 3:13 PM
> To: 'Tapestry users'
> Subject: AW: hibernate + tapestry (again for the 1,000,000th time)
>
>
> Your solution is excellent, Marcus!
>
> I am greatly impressed about the things you can do with hivemind :-)
>
> The problem I still have is:
> Maybe I didn't get every detail about your solution but it seems the
> hibernate session is not closed before the http session terminates.
> This causes some trouble if third-party applications access
> the database
> backend (-> stale cache). also the object graphs grows pretty large.
>
> Despite my long java experience I still have to experiment
> more to fully
> understand your solution in all it's consequences. I am still no
> hivemind
> expert (even though I work hard on that)
>
> Best Regards
> Peter
>
>
> -----Ursprüngliche Nachricht-----
> Von: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
> Gesendet: Freitag, 30. September 2005 14:59
> An: 'Tapestry users'
> Betreff: RE: hibernate + tapestry (again for the 1,000,000th time)
>
>
> Did you try my little Hivemind-solution? If so, what was
> wrong for you?
> I know it's not perfect, but I happen to be quite happy with it. Ok,
> ta-control is still in a IMonitor/IActionListener Combi, but
> that really
> doesn't hurt so much, does it?
>
> > -----Original Message-----
> > From: Pete [mailto:[EMAIL PROTECTED]
> > Sent: Friday, September 30, 2005 2:05 PM
> > To: [email protected]
> > Subject: hibernate + tapestry (again for the 1,000,000th time)
> >
> >
> > I am working on a implementation of
> > 'session-per-application-transaction'
> >
> > described here: http://www.hibernate.org/168.html
> >
> > Has anybody ever managed _all_ of these with hibernate + tapestry?
> >
> > - not using object-id's for reference but object references for the
> > business objects (at least within a single application transaction)
> > - not needing attach / detach / merge on a regular base to
> > resync object
> > instances with the cache
> > - not prefetching associations to avoid LazyInitializationException
> > - not using silly data transfer objects
> > - having application transactions with a lifetime of longer
> > than a simple
> > http request
> > - having automatic transaction control with commit as a default
> > - having custom transaction control in your application
> > (explicit: begin /
> > commit / rollback)
> > - clearing / closing the session at the end of the
> > transaction without
> > making long living session state objects invalid
> >
> > Maybe I am just asking for too much...
> >
> > Hibernate and Tapestry are excellent products (probably the
> > best in their
> > category)
> >
> > Just combining them will drive you _really_ insane :-(
> >
> >
> >
> ---------------------------------------------------------------------
> > To unsubscribe, e-mail: [EMAIL PROTECTED]
> > For additional commands, e-mail:
> [EMAIL PROTECTED]
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
