entitymanager does not flush ?

[elkner]

Is it possible, that in 4.0.3SP1 vanilla the entitymanager does not flush, when em.flush() is called, but at the end of a JTA, only ?

My SLSB szenario:
C1:t0) remote client creates a new entity
S1:++t0) server em.persist(entity)
S2:++t0) server em.flush()
S3:++t0) server broadcast: new entity
S4:t0+x) End of JTA
C2:t0+y) remote client receives broadcast
C3:t0+y+1) remote client fetches the new entity:
S5:t0+y+1+n) server em.find(bla.class, id) -> entity not found

Obviously S5 may occure between S3 and S4 (not sure, whether JBoss JMS delivery is threaded) if x > y+1+n, but AFAIK, since the em has been flushed the new entity should be available, even if S5 runs in another JTA than {S1..S4}.

So is it an implementation bug or did I get something wrong wrt. persistence spec?

[jsb]

I'm seeing the same behavior with RC3. I may be way off on this, but my understanding of flush is that it pushes in-memory changes to the database but does not commit the transaction; so, in a transaction aware database, the updated data is not available to other transactions until the actual commit happens. Again, I could be way off on this. Word from someone who knows would be greatly appreciated.

What bothers me, though, is that the JMS message is being delivered before the transaction has completed. This is definitely happening in my case, using RC3, where an SLSB is used to persist an entity and during the save method a message is sent to an MDB queue to request additional, asynchronous work based on the data of the new entity. Because the message is being delivered before the transaction completes occasionally the new entity is available to the MDB.

According to my understanding of the spec, a JMS message should not be delivered to its final destination until after the transaction from which it originated commits. I'm inferring this from section 12.3.5 where it says: "Because a JMS message is typically not delivered to its final destination until the transaction commits, the receipt of the reply within the same transaction will not take place."

I haven't been able to try the same out with RC5, but I hope to be able to next week.

[bill.burke]

flush() just calls JDBC updates, it doesn't commit.

For transacted JMS use the "java:/JmsXA" factory. It will send all messages at commit time.

[jsb]

Thanks Bill!!

Indeed, replacing

@Resource (mappedName="ConnectionFactory")
private QueueConnectionFactory factory;

...with...

@Resource (mappedName="java:/JmsXA")
private QueueConnectionFactory factory;

...in my SLSB has gotten me the behavior I was looking for (messages get picked up by the MDB after the transaction has completed).

Thanks for putting up with my ignorance and sharing your knowledge,
Jonn

[elkner]

flush() just calls JDBC updates, it doesn't commit.

Ahh, so I interpreted the spec not as assumed. OK, thinking a little bit more about it, it is probably not so easy to rollback already db commited data ;-)

For transacted JMS use the "java:/JmsXA" factory. It will send all messages at commit time.

That's a very good hint and seems to work :). Already thought about, whether I need to make all TAs bean managed, to accomplish that :(.

Thanx a lot,
jens.