If you're doing non-critical stuff, you don't need to worry about transactions. If you do need transactions, you can use container managed (JTA), or application managed (probably Spring). That way, you mark certain methods as transactional and the container or Spring takes care of opening the transaction at the beginning then committing at the end or rolling back in case of a RuntimeException.
On 8/1/05, Peter Veentjer - Anchor Men <[EMAIL PROTECTED]> wrote: > > I didn`t mean that. I wanted to know how many transaction where required and > I didn`t know what happened if you use a session without a transaction. I > just heard that if you used a session without a transaction the default > isolation level is a READ_COMMITED. And that is something I can live with. > So it boils down to: the only part you need a transaction is around the > event handler (if you don`t need a seperate service layer). And this makes > our thinking a hell of a lot easier :) > > ________________________________ > Van: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] Namens > Igor Vaynberg > Verzonden: maandag 1 augustus 2005 16:43 > Aan: [email protected] > Onderwerp: RE: [Wicket-user] Hibernate and Transactions (again) > > > > You use JTA transactions, that way different services can join in on the > transaction. You open a JTA transaction in the beginning of the request, all > your services/daos use that transaction, and at the end of the request you > either commit or roll back. > > -Igor > > > > ________________________________ > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] On Behalf > Of Peter Veentjer - Anchor Men > Sent: Monday, August 01, 2005 7:30 AM > To: [email protected] > Subject: [Wicket-user] Hibernate and Transactions (again) > > > > > I have another question about the length of a Hibernate transaction and > wicket. > > Normally you have a request->the model is re-attched->method call (maybe go > to some service to do some saves) -> render view. > > How do you coordinate the transaction that is to re-attach the model? If you > have a service, the service probably has his own transaction, but the > reattachement needs his own transaction also. A Session that isn`t protected > by some kind of transaction to do reads from the database could give some > strange results. How do you deal with this? > > And what if you don`t need a service, but you have a form, and the data in > the form is valid and can be submitted directly to a dao (a seperate service > layer for very-small application is imho quite useless). Do you work with a > single transaction to do the reattachement and the same transaction for the > dao.save. Or do you make different transactions? > > And what if a page activates another page? The other page his model must be > reattached (so it needs a session/transaction). Where does he get het > transaction from? Do you make a big transaction for the complete request so > that everybody has a good transaction they can use? > > As you can see there are a lot of questions about how to use Hibernate with > something like wicket and we want to understand how to deal with these > situations so we can help other programmers at our company as soon as we > switch from maverick to Wicket/Tapestry (Wicket has the most chance btw). I > hope somebody can answer my questions. > > Met vriendelijke groet, > > Peter Veentjer > Anchor Men Interactive Solutions – duidelijk in zakelijke > internetoplossingen > > Praediniussingel 41 > 9711 AE Groningen > > T: 050-3115222 > F: 050-5891696 > E: [EMAIL PROTECTED] > I : www.anchormen.nl >
