Oh and btw, even more important: don't use this neat trick for anything you really depend on in your app. Otherwise you will fail in production if the server gets booted or a cluster node gets added under heavy load.
What I mean: This trick is perfect for refreshing statistics or cleaning up old temp stuff on the disc. But it is NOT a good idea to use it to configure your application, provide important initial data for your services, etc. Why? Because it's simply not guaranteed that all those async stuff really did finish before your server gets hit by a bazillion user requests if you restart a node under load. LieGrue, strub ----- Original Message ----- > From: Mark Struberg <[email protected]> > To: "[email protected]" <[email protected]> > Cc: OpenEJB Users <[email protected]> > Sent: Thursday, 24 October 2013, 9:51 > Subject: Re: @Async call blocks in @PostConstruct > > > > And as discussed with Romain on IRC a few minutes ago: > > This works in OpenEJB, because it's smart ;) > But I would not bet a dime that this is clear from the spec. So it is > probably > not portable and possibly won't work on other EJB containers. > > There is of course an easy alternative solution. > Just move the @Asynchronous method to an own EJB and inject it. The only > thing > you must guarantee is that you don't have an injection cycle between your > @Startup and your worker EJB. > In this case you also don't need to deal with the SessionContext. Which > might be another issue: I'm not sure if it's save (again: works in > OpenEJB, but what about other EJB containers) to use the SessionContext > during > @PostConstruct. Would need to ask this on the EJB EG (or grab deep in the > spec). > > To be more clear what the real issue is: @PostConstruct is part of the > 'initialisation' of any manged instance. Like @Inject fields, methods > and constructors are. And the EJB must only be made available to the user > once > this initialisation process is 100% finished. > > LieGrue, > strub > > > > > >> ________________________________ > >> From: Romain Manni-Bucau <[email protected]> >> To: "[email protected]" <[email protected]> >> Cc: OpenEJB Users <[email protected]> >> Sent: Thursday, 24 October 2013, 9:31 >> Subject: Re: @Async call blocks in @PostConstruct >> >> >> Hi >> >> The spec mandates @PostConstruct to finish before business method are >> called. That's what we do blocking to start the @Async method. If you >> rmethod is not @Async it obviously doesn't work. >> Romain Manni-Bucau >> Twitter: @rmannibucau >> Blog: http://rmannibucau.wordpress.com/ >> LinkedIn: http://fr.linkedin.com/in/rmannibucau >> Github: https://github.com/rmannibucau >> >> >> >> >> 2013/10/24 zmirc <[email protected]>: >>> Hi! >>> >>> Mark might have a good point, which can be shown with the current > example >>> (see code). >>> By removing @Asynchronous from this EJB, Tomee does blocks for ever. >>> If @Asynchronous is not commented out, then it works perfectly, with > async >>> doingHardWork() method being executed after the @PostConstruct init(), > even >>> though it is called inside the @PostConstruct. That should be ok. >>> >>> It's maybe not so ok if @Asynchronous is removed. Shouldn't > SessionContext >>> throw an exception or something if someone tries to use it in this way > that >>> blocks Tomee deployment completely? >>> >>> Async.java > <http://openejb.979440.n4.nabble.com/file/n4665718/Async.java> >>> >>> >>> >>> -- >>> View this message in context: > http://openejb.979440.n4.nabble.com/Async-call-blocks-in-PostConstruct-tp4665703p4665718.html >>> Sent from the OpenEJB User mailing list archive at Nabble.com. >> >> >> >
