You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@tapestry.apache.org by Pete <pe...@gmx.org> on 2005/09/30 14:04:53 UTC
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: tapestry-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tapestry-user-help@jakarta.apache.org
RE: hibernate + tapestry (again for the 1,000,000th time)
Posted by Konstantin Ignatyev <kg...@yahoo.com>.
Just make sure you do not slip into:
session-per-user-session or session-per-application
And it looks like session-per-application-transaction
model is prone to that 'double submission' problem if
WEB-UI does not prevent it (default behavior)
--- Patrick Casey <pa...@adelphia.net> wrote:
>
> For my use cases it end up basically being the
> session-per-application-transaction model. I only
> use the encapsulated
> session for object that are part of a long
> transaction, otherwise I use the
> much more common session-per-transaction model.
>
> --- Pat
>
> > -----Original Message-----
> > From: Konstantin Ignatyev
> [mailto:kgignatyev@yahoo.com]
> > Sent: Friday, September 30, 2005 9:44 AM
> > To: Tapestry users
> > Subject: RE: hibernate + tapestry (again for the
> 1,000,000th time)
> >
> > This approach seems to be discouraged by Hibernate
> > team
> >
> > http://hibernate.org/168.html
> >
> >
> > --- Patrick Casey <pa...@adelphia.net> wrote:
> >
> > >
> > > Yah, it was kind of a eureka moment for me as
> well.
> > > Before that I'd
> > > struggled with a lot of different approaches to
> > > keeping the object itself
> > > associated with its session for long
> transactions.
> > > Glueing the two together
> > > though seems to have made that whole difficulty
> > > moot.
> > >
> > > --- Pat
> > >
> > > > -----Original Message-----
> > > > From: Peter Ertl [mailto:peter.ertl@gmx.net]
> > > > Sent: Friday, September 30, 2005 6:03 AM
> > > > To: 'Tapestry users'
> > > > Subject: AW: hibernate + tapestry (again for
> the
> > > 1,000,000th time)
> > > >
> > > > yes!!!!
> > > >
> > > > what a wonderful idea to put the session
> lifetime
> > > inside the DAO itself.
> > > >
> > > > you made me see the light at the end of the
> > > tunnel!!
> > > >
> > > > thank you so much !! :-))))))
> > > >
> > > > Best regards
> > > > Peter
> > > >
> > > >
> > > > -----Ursprüngliche Nachricht-----
> > > > Von: Patrick Casey
> [mailto:patcasey@adelphia.net]
> > > > Gesendet: Freitag, 30. September 2005 14:48
> > > > An: 'Tapestry users'
> > > > Betreff: RE: hibernate + tapestry (again for
> the
> > > 1,000,000th time)
> > > >
> > > >
> > > >
> > > > I just finished a major refactor to put in
> that
> > > sort of
> > > > functionality and more fine grained
> transactions.
> > > The approach I took
> > > > was to switch over to a DAO pattern and carry
> the
> > > session along with the
> > > > DAO (disconnecting at the end of the
> transaction).
> > > >
> > > > So a typical (long) transaction was:
> > > >
> > > > GenericDAO g = new GenericDAO("foo");
> > > > g.loadInstance(key);
> > > > // render view
> > > > g.disconnectSession();
> > > > // return to user
> > > > // user pushes save
> > > > // fetch g from HTTPSession
> > > > g.reconnet()
> > > > // rewind
> > > > g.doAction(Action.SAVE);
> > > >
> > > >
> > > > Basically each transaction gets its own
> private
> > > Long session
> > > > this way. For non transactional data, I
> switched
> > > back to a session per
> > > > thread pattern which seems to be working for
> me.
> > > >
> > > > --- Pat
> > > >
> > > > > -----Original Message-----
> > > > > From: Pete [mailto:pertl@gmx.org]
> > > > > Sent: Friday, September 30, 2005 5:05 AM
> > > > > To: tapestry-user@jakarta.apache.org
> > > > > 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:
> > > tapestry-user-unsubscribe@jakarta.apache.org
> > > > > For additional commands, e-mail:
> > > tapestry-user-help@jakarta.apache.org
> > > >
> > > >
> > > >
> > > >
> > > >
> > >
> >
>
---------------------------------------------------------------------
> > > > To unsubscribe, e-mail:
> > > tapestry-user-unsubscribe@jakarta.apache.org
> > > > For additional commands, e-mail:
> > > tapestry-user-help@jakarta.apache.org
> > > >
> > > >
> > > >
> > > >
> > >
> >
>
---------------------------------------------------------------------
> > > > To unsubscribe, e-mail:
> > > tapestry-user-unsubscribe@jakarta.apache.org
> > > > For additional commands, e-mail:
> > > tapestry-user-help@jakarta.apache.org
> > >
> > >
> > >
> > >
> > >
>
=== message truncated ===
Konstantin Ignatyev
PS: If this is a typical day on planet earth, humans will add fifteen million tons of carbon to the atmosphere, destroy 115 square miles of tropical rainforest, create seventy-two miles of desert, eliminate between forty to one hundred species, erode seventy-one million tons of topsoil, add 2,700 tons of CFCs to the stratosphere, and increase their population by 263,000
Bowers, C.A. The Culture of Denial: Why the Environmental Movement Needs a Strategy for Reforming Universities and Public Schools. New York: State University of New York Press, 1997: (4) (5) (p.206)
---------------------------------------------------------------------
To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tapestry-user-help@jakarta.apache.org
RE: hibernate + tapestry (again for the 1,000,000th time)
Posted by Patrick Casey <pa...@adelphia.net>.
For my use cases it end up basically being the
session-per-application-transaction model. I only use the encapsulated
session for object that are part of a long transaction, otherwise I use the
much more common session-per-transaction model.
--- Pat
> -----Original Message-----
> From: Konstantin Ignatyev [mailto:kgignatyev@yahoo.com]
> Sent: Friday, September 30, 2005 9:44 AM
> To: Tapestry users
> Subject: RE: hibernate + tapestry (again for the 1,000,000th time)
>
> This approach seems to be discouraged by Hibernate
> team
>
> http://hibernate.org/168.html
>
>
> --- Patrick Casey <pa...@adelphia.net> wrote:
>
> >
> > Yah, it was kind of a eureka moment for me as well.
> > Before that I'd
> > struggled with a lot of different approaches to
> > keeping the object itself
> > associated with its session for long transactions.
> > Glueing the two together
> > though seems to have made that whole difficulty
> > moot.
> >
> > --- Pat
> >
> > > -----Original Message-----
> > > From: Peter Ertl [mailto:peter.ertl@gmx.net]
> > > Sent: Friday, September 30, 2005 6:03 AM
> > > To: 'Tapestry users'
> > > Subject: AW: hibernate + tapestry (again for the
> > 1,000,000th time)
> > >
> > > yes!!!!
> > >
> > > what a wonderful idea to put the session lifetime
> > inside the DAO itself.
> > >
> > > you made me see the light at the end of the
> > tunnel!!
> > >
> > > thank you so much !! :-))))))
> > >
> > > Best regards
> > > Peter
> > >
> > >
> > > -----Ursprüngliche Nachricht-----
> > > Von: Patrick Casey [mailto:patcasey@adelphia.net]
> > > Gesendet: Freitag, 30. September 2005 14:48
> > > An: 'Tapestry users'
> > > Betreff: RE: hibernate + tapestry (again for the
> > 1,000,000th time)
> > >
> > >
> > >
> > > I just finished a major refactor to put in that
> > sort of
> > > functionality and more fine grained transactions.
> > The approach I took
> > > was to switch over to a DAO pattern and carry the
> > session along with the
> > > DAO (disconnecting at the end of the transaction).
> > >
> > > So a typical (long) transaction was:
> > >
> > > GenericDAO g = new GenericDAO("foo");
> > > g.loadInstance(key);
> > > // render view
> > > g.disconnectSession();
> > > // return to user
> > > // user pushes save
> > > // fetch g from HTTPSession
> > > g.reconnet()
> > > // rewind
> > > g.doAction(Action.SAVE);
> > >
> > >
> > > Basically each transaction gets its own private
> > Long session
> > > this way. For non transactional data, I switched
> > back to a session per
> > > thread pattern which seems to be working for me.
> > >
> > > --- Pat
> > >
> > > > -----Original Message-----
> > > > From: Pete [mailto:pertl@gmx.org]
> > > > Sent: Friday, September 30, 2005 5:05 AM
> > > > To: tapestry-user@jakarta.apache.org
> > > > 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:
> > tapestry-user-unsubscribe@jakarta.apache.org
> > > > For additional commands, e-mail:
> > tapestry-user-help@jakarta.apache.org
> > >
> > >
> > >
> > >
> > >
> >
> ---------------------------------------------------------------------
> > > To unsubscribe, e-mail:
> > tapestry-user-unsubscribe@jakarta.apache.org
> > > For additional commands, e-mail:
> > tapestry-user-help@jakarta.apache.org
> > >
> > >
> > >
> > >
> >
> ---------------------------------------------------------------------
> > > To unsubscribe, e-mail:
> > tapestry-user-unsubscribe@jakarta.apache.org
> > > For additional commands, e-mail:
> > tapestry-user-help@jakarta.apache.org
> >
> >
> >
> >
> >
> ---------------------------------------------------------------------
> > To unsubscribe, e-mail:
> > tapestry-user-unsubscribe@jakarta.apache.org
> > For additional commands, e-mail:
> > tapestry-user-help@jakarta.apache.org
> >
> >
>
>
> Konstantin Ignatyev
>
>
>
>
> PS: If this is a typical day on planet earth, humans will add fifteen
> million tons of carbon to the atmosphere, destroy 115 square miles of
> tropical rainforest, create seventy-two miles of desert, eliminate between
> forty to one hundred species, erode seventy-one million tons of topsoil,
> add 2,700 tons of CFCs to the stratosphere, and increase their population
> by 263,000
>
> Bowers, C.A. The Culture of Denial: Why the Environmental Movement Needs
> a Strategy for Reforming Universities and Public Schools. New York:
> State University of New York Press, 1997: (4) (5) (p.206)
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: tapestry-user-help@jakarta.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tapestry-user-help@jakarta.apache.org
RE: hibernate + tapestry (again for the 1,000,000th time)
Posted by Konstantin Ignatyev <kg...@yahoo.com>.
This approach seems to be discouraged by Hibernate
team
http://hibernate.org/168.html
--- Patrick Casey <pa...@adelphia.net> wrote:
>
> Yah, it was kind of a eureka moment for me as well.
> Before that I'd
> struggled with a lot of different approaches to
> keeping the object itself
> associated with its session for long transactions.
> Glueing the two together
> though seems to have made that whole difficulty
> moot.
>
> --- Pat
>
> > -----Original Message-----
> > From: Peter Ertl [mailto:peter.ertl@gmx.net]
> > Sent: Friday, September 30, 2005 6:03 AM
> > To: 'Tapestry users'
> > Subject: AW: hibernate + tapestry (again for the
> 1,000,000th time)
> >
> > yes!!!!
> >
> > what a wonderful idea to put the session lifetime
> inside the DAO itself.
> >
> > you made me see the light at the end of the
> tunnel!!
> >
> > thank you so much !! :-))))))
> >
> > Best regards
> > Peter
> >
> >
> > -----Ursprüngliche Nachricht-----
> > Von: Patrick Casey [mailto:patcasey@adelphia.net]
> > Gesendet: Freitag, 30. September 2005 14:48
> > An: 'Tapestry users'
> > Betreff: RE: hibernate + tapestry (again for the
> 1,000,000th time)
> >
> >
> >
> > I just finished a major refactor to put in that
> sort of
> > functionality and more fine grained transactions.
> The approach I took
> > was to switch over to a DAO pattern and carry the
> session along with the
> > DAO (disconnecting at the end of the transaction).
> >
> > So a typical (long) transaction was:
> >
> > GenericDAO g = new GenericDAO("foo");
> > g.loadInstance(key);
> > // render view
> > g.disconnectSession();
> > // return to user
> > // user pushes save
> > // fetch g from HTTPSession
> > g.reconnet()
> > // rewind
> > g.doAction(Action.SAVE);
> >
> >
> > Basically each transaction gets its own private
> Long session
> > this way. For non transactional data, I switched
> back to a session per
> > thread pattern which seems to be working for me.
> >
> > --- Pat
> >
> > > -----Original Message-----
> > > From: Pete [mailto:pertl@gmx.org]
> > > Sent: Friday, September 30, 2005 5:05 AM
> > > To: tapestry-user@jakarta.apache.org
> > > 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:
> tapestry-user-unsubscribe@jakarta.apache.org
> > > For additional commands, e-mail:
> tapestry-user-help@jakarta.apache.org
> >
> >
> >
> >
> >
>
---------------------------------------------------------------------
> > To unsubscribe, e-mail:
> tapestry-user-unsubscribe@jakarta.apache.org
> > For additional commands, e-mail:
> tapestry-user-help@jakarta.apache.org
> >
> >
> >
> >
>
---------------------------------------------------------------------
> > To unsubscribe, e-mail:
> tapestry-user-unsubscribe@jakarta.apache.org
> > For additional commands, e-mail:
> tapestry-user-help@jakarta.apache.org
>
>
>
>
>
---------------------------------------------------------------------
> To unsubscribe, e-mail:
> tapestry-user-unsubscribe@jakarta.apache.org
> For additional commands, e-mail:
> tapestry-user-help@jakarta.apache.org
>
>
Konstantin Ignatyev
PS: If this is a typical day on planet earth, humans will add fifteen million tons of carbon to the atmosphere, destroy 115 square miles of tropical rainforest, create seventy-two miles of desert, eliminate between forty to one hundred species, erode seventy-one million tons of topsoil, add 2,700 tons of CFCs to the stratosphere, and increase their population by 263,000
Bowers, C.A. The Culture of Denial: Why the Environmental Movement Needs a Strategy for Reforming Universities and Public Schools. New York: State University of New York Press, 1997: (4) (5) (p.206)
---------------------------------------------------------------------
To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tapestry-user-help@jakarta.apache.org
RE: hibernate + tapestry (again for the 1,000,000th time)
Posted by Patrick Casey <pa...@adelphia.net>.
Yah, it was kind of a eureka moment for me as well. Before that I'd
struggled with a lot of different approaches to keeping the object itself
associated with its session for long transactions. Glueing the two together
though seems to have made that whole difficulty moot.
--- Pat
> -----Original Message-----
> From: Peter Ertl [mailto:peter.ertl@gmx.net]
> Sent: Friday, September 30, 2005 6:03 AM
> To: 'Tapestry users'
> Subject: AW: hibernate + tapestry (again for the 1,000,000th time)
>
> yes!!!!
>
> what a wonderful idea to put the session lifetime inside the DAO itself.
>
> you made me see the light at the end of the tunnel!!
>
> thank you so much !! :-))))))
>
> Best regards
> Peter
>
>
> -----Ursprüngliche Nachricht-----
> Von: Patrick Casey [mailto:patcasey@adelphia.net]
> Gesendet: Freitag, 30. September 2005 14:48
> An: 'Tapestry users'
> Betreff: RE: hibernate + tapestry (again for the 1,000,000th time)
>
>
>
> I just finished a major refactor to put in that sort of
> functionality and more fine grained transactions. The approach I took
> was to switch over to a DAO pattern and carry the session along with the
> DAO (disconnecting at the end of the transaction).
>
> So a typical (long) transaction was:
>
> GenericDAO g = new GenericDAO("foo");
> g.loadInstance(key);
> // render view
> g.disconnectSession();
> // return to user
> // user pushes save
> // fetch g from HTTPSession
> g.reconnet()
> // rewind
> g.doAction(Action.SAVE);
>
>
> Basically each transaction gets its own private Long session
> this way. For non transactional data, I switched back to a session per
> thread pattern which seems to be working for me.
>
> --- Pat
>
> > -----Original Message-----
> > From: Pete [mailto:pertl@gmx.org]
> > Sent: Friday, September 30, 2005 5:05 AM
> > To: tapestry-user@jakarta.apache.org
> > 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: tapestry-user-unsubscribe@jakarta.apache.org
> > For additional commands, e-mail: tapestry-user-help@jakarta.apache.org
>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: tapestry-user-help@jakarta.apache.org
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: tapestry-user-help@jakarta.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tapestry-user-help@jakarta.apache.org
AW: hibernate + tapestry (again for the 1,000,000th time)
Posted by Peter Ertl <pe...@gmx.net>.
yes!!!!
what a wonderful idea to put the session lifetime inside the DAO itself.
you made me see the light at the end of the tunnel!!
thank you so much !! :-))))))
Best regards
Peter
-----Ursprüngliche Nachricht-----
Von: Patrick Casey [mailto:patcasey@adelphia.net]
Gesendet: Freitag, 30. September 2005 14:48
An: 'Tapestry users'
Betreff: RE: hibernate + tapestry (again for the 1,000,000th time)
I just finished a major refactor to put in that sort of
functionality and more fine grained transactions. The approach I took
was to switch over to a DAO pattern and carry the session along with the
DAO (disconnecting at the end of the transaction).
So a typical (long) transaction was:
GenericDAO g = new GenericDAO("foo");
g.loadInstance(key);
// render view
g.disconnectSession();
// return to user
// user pushes save
// fetch g from HTTPSession
g.reconnet()
// rewind
g.doAction(Action.SAVE);
Basically each transaction gets its own private Long session
this way. For non transactional data, I switched back to a session per
thread pattern which seems to be working for me.
--- Pat
> -----Original Message-----
> From: Pete [mailto:pertl@gmx.org]
> Sent: Friday, September 30, 2005 5:05 AM
> To: tapestry-user@jakarta.apache.org
> 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: tapestry-user-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: tapestry-user-help@jakarta.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tapestry-user-help@jakarta.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tapestry-user-help@jakarta.apache.org
RE: hibernate + tapestry (again for the 1,000,000th time)
Posted by Patrick Casey <pa...@adelphia.net>.
I just finished a major refactor to put in that sort of
functionality and more fine grained transactions. The approach I took was to
switch over to a DAO pattern and carry the session along with the DAO
(disconnecting at the end of the transaction).
So a typical (long) transaction was:
GenericDAO g = new GenericDAO("foo");
g.loadInstance(key);
// render view
g.disconnectSession();
// return to user
// user pushes save
// fetch g from HTTPSession
g.reconnet()
// rewind
g.doAction(Action.SAVE);
Basically each transaction gets its own private Long session this
way. For non transactional data, I switched back to a session per thread
pattern which seems to be working for me.
--- Pat
> -----Original Message-----
> From: Pete [mailto:pertl@gmx.org]
> Sent: Friday, September 30, 2005 5:05 AM
> To: tapestry-user@jakarta.apache.org
> 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: tapestry-user-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: tapestry-user-help@jakarta.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tapestry-user-help@jakarta.apache.org