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
smime.p7s
Description: S/MIME Cryptographic Signature
