Alexander Snaps on 01/05/08 12:02, wrote:
Entity myEntity = em.find(Entity.class, someId);
oldValue = myEntity.getSomeField(); // this is only for further down in the
mail ;)
myEntity.setSomeField(someValue);
if(!hasError) {
EntityTransaction tx = em.getTransaction();
tx.begin();
tx.commit(); // Flushes state to DB
} else {
// do whatever _outside_ of any transaction, like re-ask user to re-enter
data
}
Indeed calling the clear operation on the entity manager also results in
all managed entities becoming detached. Beyond many operations on the
current persistence context might result in the entity manager flushing
state to the database. Yet having it behave differently because of
updating managed entities outside of the tx also sometimes have the
persistence context not behave as one would expect...
I'm afraid I can't quite follow you there. (Use of 'beyond'?) The clear
operation is exactly what I want to do - with the result you mention. This
is the start of a request (HTTP param conversion and calling setters on
model properties), with a new EntityManager, so anything that goes wrong
should cause everything to be cleared.
An example of what I mean is if now you'd query for every Entity with
someField == oldValue (see above), you'd still get the same instance as
myEntity, which would have myEntity.getSomeField().equals(oldValue) ==
false!
Yes true but you're not really making use of the struts interceptor framework
here, which should keep from doing things like that.
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
