|-----Original Message-----
|From: [EMAIL PROTECTED]
|[mailto:[EMAIL PROTECTED]]On Behalf Of Rickard Oberg
|Sent: Saturday, October 21, 2000 2:00 PM
|To: jBoss Developer
|Subject: Re: [jBoss-Dev] Release lock bug in JDK? Fixed ?
|
|
|> |Sorry, I'm not following here. What exactly is the problem?
|>
|> If you call an instance and check the Tx you will go in the
|block. Now if
|> it is called from something else than the instance (bean or client) then
|it
|> is OK, just a new participating thread in the block, blah blah.
|but if it
|> is from the instance and in the instance we still need an exception... we
|> still need to detect the instance callback... not portable, hard, for
|> what????
|
|Still not following. If bean A is called in a tx, calls B, which calls A,
|then we will not block, but will get to the line
|if (!isCallAllowed(mi))
|now, if the call is not allowed (i.e. it is not a home call, and
|the bean is
|not reentrant), then a remoteexception should be thrown. Currently the code
|does a wait, as if it should wait for the lock to be released (which will
|never happen since it's the same tx that is holding it). Why? Why has the
|"throw remoteexception" code been commented out?
|
|I don't see the problem... argh...
|
|Can you be even more explicit?
yes
the piece of code does take care of the case you describe above but it also
takes care of valid cases clientA and clientB call beanA in the same Tx.
yes?
this test does more than is needed. In fact does wrong stuff...
(invalidates the above scenario)
marc (yes? see it? I am completely off-base?)
|
|Sorry,
| Rickard
|
|
|
|
