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 NOT >>>>>> >>>>>> starting >>>>> >>>>> a transaction at all in the case of a validation error... Shoudn't the >>>>>> transaction 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 the >>>> behavior 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] > > -- Alexander Snaps <[EMAIL PROTECTED]> http://www.jroller.com/page/greenhorn http://www.linkedin.com/in/alexandersnaps
