Hi Yee, I might have missed something... But why not using OSIV (yeah again I know :P) and get rid of all those transaction issues ?
IMHO, binding to persistent entities, and using in the UI tier in general, without DTOs, is much, much, much easier with OSIV. In the end, Hibernate's imposed constraints will wreck your declarative tx management. @Service works much better when used with DTOs. And it can even be perfected thanks to the solution proposed quite some time ago on this list by Jan : http://article.gmane.org/gmane.comp.java.stripes.user/5834 (a very good idea that fixes the glitches in OSIV related to long-lasting transactions and stuff like that, although it's never been a problem for me in practise). Cheers Remi 2009/6/23 CN Yee <[email protected]>: > DaveMark <djdavem...@...> writes: > >> >> >> Hello again, >> >> > Yes, this is the crux of the problem. >> > It is related to the Session per >> > request pattern in conjunction with >> > Hibernate Managed Session facility. >> >> Yes, I'd say you may need to rethink how you're doing things in regards to > your Hibernate/Spring >> configuration. For ex. The Spring @Service annotation allows transparent use > of declarative >> transaction management. >> > > > I just confirmed that the problem lies with hibernate. > > The following code will persist everything in the session to database. > > Session s = sessionFactory.getCurrentSession(); > Transaction tx = s.beginTransaction(); > tx.commit(); > > That is very nasty. Anybody has any experience to share regarding this? > > Regards, > Yee > > > > http://static.springframework.org/spring/docs/2.5.x/reference/transaction.html#transaction-declarative >> >> You already have: >> >> customerService.findById(Long) >> >> which should use its own transaction, then: >> >> customerService.makePersistent(Customer); >> >> which should use it's own as well. You can set Spring up to > open/commit/rollback on methods called >> find*/make*/update*. In your case, I see you're updating customer >> information, > and just want to put the >> 'correct' customer in place before Stripes does the binding process so you >> can > simply call makePersist(...). >> >> We used JPA (with Hibernate) configured through Spring with declarative > transactions on certain >> "@Service" methods, and exception translation on our "@Repository"s, and this > worked fine doing the >> same thing that you're doing. >> >> NOTE: I hope you've check that a mallicous user hasn't modified the > "customerId" that gets sent back! >> (encryted=true?) Are the users Admins? >> If not, since I'm guessing you already 'loaded' the customer to show their > details, why not just put the >> customer in the session and then preBind/hydrate this customer instead of > hitting the DB. Used in >> conjuction with @StrictBinding, the malicious user will also have been taken > care off. >> >> Cheers, >> >> Dave >> > > > > > > ------------------------------------------------------------------------------ > Are you an open source citizen? Join us for the Open Source Bridge conference! > Portland, OR, June 17-19. Two days of sessions, one day of unconference: $250. > Need another reason to go? 24-hour hacker lounge. Register today! > http://ad.doubleclick.net/clk;215844324;13503038;v?http://opensourcebridge.org > _______________________________________________ > Stripes-users mailing list > [email protected] > https://lists.sourceforge.net/lists/listinfo/stripes-users > ------------------------------------------------------------------------------ Are you an open source citizen? Join us for the Open Source Bridge conference! Portland, OR, June 17-19. Two days of sessions, one day of unconference: $250. Need another reason to go? 24-hour hacker lounge. Register today! http://ad.doubleclick.net/clk;215844324;13503038;v?http://opensourcebridge.org _______________________________________________ Stripes-users mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/stripes-users
