Re: Fundamental flaw in Model-Driven?

[Adam Hardy]

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]