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. 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 . . . > > Message: 7 > Date: Tue, 23 Jun 2009 09:06:11 +0800 > From: CN Yee <[email protected]> > Subject: Re: [Stripes-users] Danger with binding to Domain > Object > To: [email protected] > Message-ID: > <[email protected]> > Content-Type: text/plain; charset="iso-8859-1" > > Hi Dave, > > Thanks for your reply. But the situation is quite > intricate. Consider the > following action bean: > > public Customer customer; > > > @Before(stages=LifecycleStage.BindingAndValidation) > public void preBind() > { > String id = > getContext().getRequest().getParameter("customerId"); > customer = > customerService.findById(Long.valueOf(id)); > } > > @DefaultHandler > public Resolution view() { > return new > ForwardResolution("/editCustomer.jsp"); > } > > public Resolution save() { > > customerService.makePersistent(customer); > ... > } > > public Resolution cancel() { > return new > RedirectResolution("/listCustomer.jsp"); > } > > The preBind() method pre-loads the customer domain object, > where stripes > binding will bind direct to it. The save() method can > simply persist the > domain object without having to use a data transfer object > and a whole heaps > of codes to copy properties. This is the binding direct to > domain object > pattern advocated in > http://www.stripesframework.org/display/stripes/Binding+Into+Domain+Models. > > > Now let say I want to introduce the following method: > > > @After(stages=LifecycleStage.BindingAndValidation) > public void afterBind() { > states = > lookupService.getStateCodes(customer.getCountry()); > } > > The method is to load the list of states to populate a > dropdown list. Fair > enough use case. > > Now consider the user press the 'cancel' button. > > - preBind() loads the domain object > - stripes binding binds the post back values. > - afterBind() kicks in, lookupService got invoked. Now > since LookupService > is managed by the Transaction Manager, it is surrounded by > open and commit > transaction. With hibernate's session per request pattern, > LookupService > will also persist the customer object as well, since it is > also in the > session that LookupService is using. > > I know I can use > @Before(stages=LifecycleStage.BindingAndValidation, > on="!cancel") to get around this problem. I can probably > tweak the > Transaction Manager to always open a separate transaction. > But after some > days of thinking - it seems to me that there is simply to > many ways for > things to go wrong. The binding direct to domain model > pattern does not > seems to be tenable. > > Best regards, > Yee > -------------- next part -------------- > An HTML attachment was scrubbed... > > ------------------------------ > > ------------------------------------------------------------------------------ > 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 > > > End of Stripes-users Digest, Vol 37, Issue 28 > ********************************************* > ------------------------------------------------------------------------------ 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
