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]
