-
1. Re: Synchronization of Stateful Session Bean
starksm64 Jun 20, 2004 2:07 AM (in response to fruehbeck)Change the stateful session interceptor to synchronize calls instead of throwing an exception or add a client interceptor that does the synchronization on the client side.
-
2. Re: Synchronization of Stateful Session Bean
fruehbeck Jun 20, 2004 6:00 AM (in response to fruehbeck)Thanks for the immediate response!
My situation unfortunately doesn't provide the second possibility, because the clients are connected via CORBA (SFSB are TIE servants) so there will be no client interceptor stack, isn't it?.
I really would have liked to implement the client interceptor, because I really like this concept.
A problem I see with the stateful interceptor is the possibility of deadlock. I had a short experimental hack at the QueuedPessimisticEJBLock (inserting the EntityLockInterceptor in the container interceptor stack) which provides deadlock protection.
Do you think it's worth while investing in the idea?
At the moment I don't see far enough to be able to decide if I ever get to the bottom of the Tx-oriented locking.
I had to remove some consistency checks (eg. regarding the change of transactional context), and so I am afraid that I entered into programmatic states that the code was not intended to cope with.
I am at the moment stuck with a continuous sequence of "Start wait on TxLock" / "End wait on TxLock" of the two racing threads till the Tx expires - and both get an Exception.
Regards. -
3. Re: Synchronization of Stateful Session Bean
fruehbeck Jun 22, 2004 6:20 AM (in response to fruehbeck)Hi,
I think I found my error. It seems to work!
Many thanks for the support.
Thomas -
4. Re: Synchronization of Stateful Session Bean
ereze Aug 4, 2004 2:34 PM (in response to fruehbeck)"scott.stark@jboss.org" wrote:
Change the stateful session interceptor to synchronize calls instead of throwing an exception or add a client interceptor that does the synchronization on the client side.
How do you do that?
--Erez