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
