You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@tapestry.apache.org by Ted Steen <te...@gmail.com> on 2006/01/09 12:19:12 UTC
transaction start and end
Hi!
I`m planning on having my hibernate transaction span over one page request..
Is pageAttached(...) and pageDetached(...) the right place to start
and end the transaction?
I guess this is the first and last thing that happen on a request.
Also, is it wise to have the transaction scope over a whole page like
this? or should I use several small transactions for each db
operation? I mean, what is generally considered good design?
I'm using the "hibernate squeezer" (
http://wiki.apache.org/jakarta-tapestry/HibernateTapestrySqueezer )
thanks!
/ted
---------------------------------------------------------------------
To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tapestry-user-help@jakarta.apache.org
Re: transaction start and end
Posted by "Filip S. Adamsen" <fi...@stubkjaer-adamsen.dk>.
Ted Steen wrote:
> I think I need to read up on those TransactionInterceptors and engine
> services :)
> If you got some good reading on these topics I would be glad to have a
> look at it.
These are some of the services you can intercept, I've been thinking
about intercepting the Page (and related) service(s) to take care of
authentication in a system I'm developing at the moment.
http://jakarta.apache.org/tapestry/tapestry/hivedocs/module/tapestry.services.html
This is the HiveModule element used to intercept already existing
services with:
http://jakarta.apache.org/hivemind/descriptor.html#interceptor
And this is the HiveTranse quick start section about transaction
handling via method interception:
http://hivetranse.sourceforge.net/quickstart.html#start.config.transaction
> What do you think of the whole HibernateSqueezer idea? in order to
> unsqueeze I need a transaction started when the unsqueezing is taking
> place. maybe that is done with the interceptors and engine services?
To be honest I haven't looked at the HibernateSqueezer yet, but I guess
I will have to do that in a moment. Again, it wouldn't really be a
problem for me because I use the session-per-request pattern, so as soon
as I need a Session it will be opened by my SessionManager service and
then stay open until I close it or the request ends, whichever comes first.
If the unsqueezing is done by a service you could defintely intercept
that service providing a TransactionInterceptor instance on the
unsqueezing method.
> I am taking my first trembling steps into the db-layer, transaction
> handling world and I obviously need some guidance.
Hehe, I'm actually just a 19-year old upper-secondary school student
myself and only recently delved into transaction handling and stuff.
I'm sure people on both the Tapestry and HiveMind user lists will be
happy to help if you have any further questions, though - I know I'll do
what I can.
Regards,
Filip
Re: transaction start and end
Posted by Ted Steen <te...@gmail.com>.
I think I need to read up on those TransactionInterceptors and engine
services :)
If you got some good reading on these topics I would be glad to have a
look at it.
What do you think of the whole HibernateSqueezer idea? in order to
unsqueeze I need a transaction started when the unsqueezing is taking
place. maybe that is done with the interceptors and engine services?
I am taking my first trembling steps into the db-layer, transaction
handling world and I obviously need some guidance.
On 1/9/06, Filip S. Adamsen <fi...@stubkjaer-adamsen.dk> wrote:
> Ted Steen wrote:
> > A nice thing with transactions scoping the whole page request is that
> > properties bound to components, and thus updated by tapestry, will be
> > committed "transparently" thanks to hibernate. but you still got a
> > point with the logically grouped database interactions.
> >
> > It would be nice to do the small, logically grouped transactions
> > first, and then start a big transaction for tapestry to unsqeeze
> > parameters etc. and update changed properties.
>
> I don't like this approach, to be honest. You lose control of what is
> updated and when, instead of handling it in listener methods and the
> like. It's certainly not an approaced I would be comfortable with, at
> least. But you might have a reason for doing it this way?
>
> > the session is handled by hivetranse (a really nice hivemind service
> > that handles session creation and injection of session, transaction
> > handling etc..)
> > so session handling is not a problem. I am, on the other hand,
> > wondering where to start the transaction if I where to span over the
> > whole page request. My first thoughts where, as I said,
> > pageAttach(...) and pageDetach(...).
>
> Hmm, since you're using HiveTranse you could perhaps use its
> TransactionInterceptor on Tapestry's relevant engine services?
>
> Regards,
> Filip
>
>
>
--
/ted
---------------------------------------------------------------------
To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tapestry-user-help@jakarta.apache.org
Re: transaction start and end
Posted by "Filip S. Adamsen" <fi...@stubkjaer-adamsen.dk>.
Ted Steen wrote:
> A nice thing with transactions scoping the whole page request is that
> properties bound to components, and thus updated by tapestry, will be
> committed "transparently" thanks to hibernate. but you still got a
> point with the logically grouped database interactions.
>
> It would be nice to do the small, logically grouped transactions
> first, and then start a big transaction for tapestry to unsqeeze
> parameters etc. and update changed properties.
I don't like this approach, to be honest. You lose control of what is
updated and when, instead of handling it in listener methods and the
like. It's certainly not an approaced I would be comfortable with, at
least. But you might have a reason for doing it this way?
> the session is handled by hivetranse (a really nice hivemind service
> that handles session creation and injection of session, transaction
> handling etc..)
> so session handling is not a problem. I am, on the other hand,
> wondering where to start the transaction if I where to span over the
> whole page request. My first thoughts where, as I said,
> pageAttach(...) and pageDetach(...).
Hmm, since you're using HiveTranse you could perhaps use its
TransactionInterceptor on Tapestry's relevant engine services?
Regards,
Filip
Re: transaction start and end
Posted by Ted Steen <te...@gmail.com>.
A nice thing with transactions scoping the whole page request is that
properties bound to components, and thus updated by tapestry, will be
committed "transparently" thanks to hibernate. but you still got a
point with the logically grouped database interactions.
It would be nice to do the small, logically grouped transactions
first, and then start a big transaction for tapestry to unsqeeze
parameters etc. and update changed properties.
the session is handled by hivetranse (a really nice hivemind service
that handles session creation and injection of session, transaction
handling etc..)
so session handling is not a problem. I am, on the other hand,
wondering where to start the transaction if I where to span over the
whole page request. My first thoughts where, as I said,
pageAttach(...) and pageDetach(...).
On 1/9/06, Filip S. Adamsen <fi...@stubkjaer-adamsen.dk> wrote:
> Hi Ted,
>
> I wouldn't recommend the approach you're taking here. Instead of having
> the Hibernate transaction span over one page request, you should - as
> you said yourself - use multiple transactions for logically grouped
> database interactions.
>
> It is much better to have one Session span over one page request
> instead. I don't know if it's recommended to put Session handling code
> in pageAttached and pageDetached - I'm on Tapestry 4.0 myself, and I'm
> using a HiveMind service to take care of this, so my Session's scope is
> per request.
>
> Regards,
> Filip
>
> Ted Steen wrote:
> > Hi!
> >
> > I`m planning on having my hibernate transaction span over one page request..
> > Is pageAttached(...) and pageDetached(...) the right place to start
> > and end the transaction?
> > I guess this is the first and last thing that happen on a request.
> > Also, is it wise to have the transaction scope over a whole page like
> > this? or should I use several small transactions for each db
> > operation? I mean, what is generally considered good design?
> >
> > I'm using the "hibernate squeezer" (
> > http://wiki.apache.org/jakarta-tapestry/HibernateTapestrySqueezer )
> >
> >
> > thanks!
> > /ted
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
> > For additional commands, e-mail: tapestry-user-help@jakarta.apache.org
> >
> >
>
>
>
--
/ted
---------------------------------------------------------------------
To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tapestry-user-help@jakarta.apache.org
Re: transaction start and end
Posted by "Filip S. Adamsen" <fi...@stubkjaer-adamsen.dk>.
Hi Ted,
I wouldn't recommend the approach you're taking here. Instead of having
the Hibernate transaction span over one page request, you should - as
you said yourself - use multiple transactions for logically grouped
database interactions.
It is much better to have one Session span over one page request
instead. I don't know if it's recommended to put Session handling code
in pageAttached and pageDetached - I'm on Tapestry 4.0 myself, and I'm
using a HiveMind service to take care of this, so my Session's scope is
per request.
Regards,
Filip
Ted Steen wrote:
> Hi!
>
> I`m planning on having my hibernate transaction span over one page request..
> Is pageAttached(...) and pageDetached(...) the right place to start
> and end the transaction?
> I guess this is the first and last thing that happen on a request.
> Also, is it wise to have the transaction scope over a whole page like
> this? or should I use several small transactions for each db
> operation? I mean, what is generally considered good design?
>
> I'm using the "hibernate squeezer" (
> http://wiki.apache.org/jakarta-tapestry/HibernateTapestrySqueezer )
>
>
> thanks!
> /ted
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: tapestry-user-help@jakarta.apache.org
>
>