Hi Romain,
[about not being able to get a new instance of a SFSB after the
original
one was destroyed by timeout]
because it would be inconsistent. If you use a statetful it means you
need a state so if you have a new instance you loose your state
But if (when) I really WANT a new instance? The same business process
could be
instantiated many times by the same user. Maybe not in parallel, but
one after another.
There are lifecycle events (@PreDestroy) so I know when/if my state was
discarded.
During EJB 2.x days, I could call create() many times for the same
SFSB, from the same web session. But with EJB3.x I can't find a way to
create my SFSB instances. Be it using annotations or JNDI lookups, I get
a new instance the first time, and after timeout or after I explicit
call a "destroy" method, I cannot get another new instance.
So, isn't this really supposed to work? As it worked for EJB2.x, I
wondered I was doing something wrong witj EJB 3.x. :-(
I think it's very bad that, after an SFSB gets discarded by timeout, I
have no way to keep my appgoing. All attempts to get a reference to the
SFSB throw exceptions. I'm forced to invalidate the user web session.
There should be a way for my app to recover from an SFSB timeout.
Think about an app that uses services provided by an SFSB developed
elsewere. That SFSB timeout is none the app business. But the way it is,
I'm forced to have a smaller timeout for the web session than the SFSB
timeout. Even then, I cannot make sure the SFSB will be called again, to
keep it alive, while the user navigates the web app. It's absurd to have
a "noop" call to the SFSB just to keep it alive. I can't understand why
the SFSB timeout should be a non-recoverable scenario.
[]s, Fernando
