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... > > Now perhaps an alternate approach: > start a transaction near the very beginning of the interceptor stack > commit, in application code, re-open a new (clean) session for OSIV > usage, would need to reattach objects...... > rollback, always in the OSIV/OEMIV filters > > > Eric > > > --------------------------------------------------------------------- > 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
