But if you use the @Asynchronous at the observer method, then the SENDER doesn't know about it. And this might introduce concurrency issues as outlined in my comment. I did explain this on IRC but happy to repeat it: EJB @Asynchronous and similar stuff (@Async) is imo pretty much useless for 98% of all usecases as it is NOT reliable! What do I mean? A real world example from our project (university management software). Imagine a lecturer at the university issues a course certificate. It doesn't take that long to store the new certificate into our database, but it takes up to 5 minutes to do all the 'backoffice' stuff like calculate course grade medians, scholarship criteria calculations etc. This also includes talking to some government SAP backends which could also take a bit. We originally thought that using @Asynchronous would be a perfect fit, but in fact that doesn't give you any guarantees! It's basically only fire and forget and doesn't make sure that the stuff really did succeed. If there is an Exception in the asynchronous task, you will NOT get notified and have no chance to react. If the Session gets killed via a logout, you might loose all data. If the server goes down, you will loose all data, etc It is also not specified/guaranteed that Session and Request Contexts will get propagated. Au contraire, it is highly suggested to NOT propagate them because of the side effects it could have. In all cases where you need RELIABLE results, I'd suggest to do it old-school: just write an entry into a 'tasks' table and poll it with a Quartz or @Timer job which does the work fully transactional. That way you can even setup again after a crash without loosing data. @Asynchronous is really only usable for stuff you don't need to really work but is only 'nice to have'. just my .02 ... LieGrue, strub ----- Original Message -----