-
1. Re: Message from the future!
Your design strategy seems a bit tricky to me. Do not forget that JMS is basically asynchronous or, if you prefer, the producer and the consumer(s) of a JMS message are *NOT* in the same transaction.
Anyway, if want to keep your strategy, why not putting your JMS messages inside the transaction that commits the data. That way, messages will be available only when the transaction has been comitted (i.e. when data has been updated)
Does this solve your problem? -
2. Re: Message from the future!
I know it sounds a tricky and maybe it is tricky. But if I can send the message after the commit there is not much that can go wrong. (I hope)
What do you mean with putting my message in the transaction? At this moment the last thing I do when I call a method in my session is sending the message. If I'm not mistaken this means the jms is in the same transaction? Am I wrong?
It looks like this :
public class Message.... {
//transaction-attribute: required
public void fire() {
//fires jms
}
}
public class Session ... {
//transaction-attribute : required
public void doStuff() {
//do entity stuff
...fire();
}
}
I also tried to replace the required attribute from the firing to RequiresNew. Which means that the current transaction is SUSPENDED and a new transaction is started. The question is whether the transaction is suspended or ended. I know it is(should be) finished ... but does the transaction knows it. Arghh, it gives me an headache! -
3. Re: Message from the future!
The datasource, jms is using as persistent store must be configured as managed resource for your session bean. Probably you have to use XA transactions since your transactional work with your session bean and the sending of the message are on different datasources.
Your bean must be configured with a transaction (required, requiresNew). Don't call commit by yourself (not even jms), since all the transactional work will be commited container managed.
Greetings,
Frito -
4. Re: Message from the future!
thanks guys,
To explain the function of the app: basically it starts with a Java app client program that invokes a Sessionbean running non transactionally(TX_NOTSUPPORTED).
The Sessionbean sends messages to several MessageBeans which also runs non transactional - and thats it.
The messagebeans now runs async and do the grunt database work (Oracle) by accessing entitybeans that runs transactional as would be expected.
My problem is that if JBoss gets killed while the messagebeans processes. Then when JBoss is restarted, the App wont start and we have to clean those temp files as described... -