Adam Hardy
Thu, 08 May 2008 15:36:53 -0700
Hi Alex, no, unfortunately I'm not in San Francisco at the moment :(Your comments though led me to check my configuration and I realised that I had set up transactions in Spring even for pure reads which I think we used on our last project and I never looked at it again. Copy & paste got me again.
So now I set up transactionless reads. This means I can simply insert all the incoming HTTP params into my model, and if struts validation fails, it all drops out of the EntityManager once my OpenSessionInView closes it up.
Much more logical and intuitive I think, after all - apart from that update() situation.
Alexander Snaps on 08/05/08 22:02, wrote:
Still didn't take the time to look into the code :( By any chance, are you at JavaOne? We might try to check it out together, what do you think? Alex On Fri, May 2, 2008 at 4:01 AM, Adam Hardy <[EMAIL PROTECTED]> wrote:My curiosity finally got the better of me and I put the JPA transaction issue to test, and I have to concur with you. What threw me off the scent is the update method I have on my business managers, on which the transactional boundary is set in Spring. The update() method doesn't sit well with JPA. As you rightly said, all that is needed to trigger an update is a transaction. In effect, the update() method on my business manager doesn't have to contain any code at all - just the fact that it invokes the transaction will be enough to ensure that all the entities in the entity manager are flushed. And that's not good for intuitiveness - if someone new read the code and saw that I had edited 2 entities but only called update() on one, they would obviously ask why on earth the second entity magically updated. I guess I'll have to work out a refactoring. Alexander Snaps on 02/05/08 10:18, wrote:It'll probably be around the tx...I've been doing this within Swing apps, trying to fix the wizard in Netbeans around JSR 295, 296 and JPA. Come see my presentation at JavaOne on the subject ;) But I need to see if this can be applied to this situation. I still don't get how changes done while applying the values actually are within a tx demarcation... Doesn't translate in some weird tx management issue? Why would you have the tx begin during these phases? On Fri, May 2, 2008 at 11:11 AM, Adam Hardy < [EMAIL PROTECTED]> wrote: Alexander Snaps on 02/05/08 10:04, wrote:On Thu, May 1, 2008 at 5:49 PM, Eric D. Nielsen <[EMAIL PROTECTED]>wrote: Alexander Snaps <alex.snaps <at> gmail.com> writes:I know I am repeating myself, but what is getting in the way of NOTstartinga transaction at all in the case of a validation error... Shoudn't thetransaction be started much later anyways, and only if validation passed?Because that doesn't solve the problem. No transaction has been started explicitly. The underlying problem is that there are two sources of implicit transactions that can be triggered. 1) Explict session/entityManager.flush() in the cleanup code of OSIV/OEMIV filters 2) Implicit flush before queries. FlushMode settings appear to help in some cases, but I've seen reports where it appears that the setting isn't always respected. If a transaction hasn't been started, either of these cases (ie falling out the bottom of OSIV/OEMIV, or a lazy load query) can trigger writing data to the DB. no, w/o tx nothing ever gets flushed to the db... I explained thebehavior you'd get in a previous message. I'll check out the code on my flight to SF (should I remember to check it out of scm ;) ) I'll try to get back to you with something more concrete... I for one will be interested to see what you come up with!--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]