You don't want the flush happening automatically. One of the benefits of systems like the JPA is their ability to batch up changes made to the data and send out batched SQL all at once.
For example:
[code]
// Assume this is running withing a Stateless Session Bean
public void test() {
MyObj o = em.find(MyObj.class, 1);
o.this = "something new!";
o.that = "something else";
}
[/code]
This code will fetch the 'o' object, and change two fields, then persist those changes to the DB. But it won't do it until after it has exited the method, and the wrapping transaction is committed. Note that there is no explicit call to the entityManager to update the row, that happens automatically as in this specific case, the o object is still "managed" by the entityManager.
If it "auto-flushed", it would make two seperate update statements here (which you most certainly don't want).
Now, deletes are a special case, and being explicit about using flush there can be relevant. But most explicit deletes (for normal maintenance) can be avoided by leveraging the em.merge() operation properly.
As for you specific scenario, I just want to make sure you're aware that your modify method isn't the way you would normally change a row in the DB using JPA.
Rather, you should simply call entityManager.merge(...) on your detached row, then the JPA will make the necessary changes for you.
[Message sent by forum member 'whartung' (whartung)]
http://forums.java.net/jive/thread.jspa?messageID=224612