> -----Original Message-----
> From: Rickard Oberg [mailto:[EMAIL PROTECTED]]
> Sent: Friday, December 01, 2000 4:52 AM
> To: jBoss
> Subject: Re: [jBoss-User] deadlock accessing EntityBeans
>
>
> Hi!
>
> "Nortje, Andrew" wrote:
> > You can define your entity beans to be reentrant in
> ejb-jar.xml like this.
> > This might fix your problem. The J2EE spec discourages
> this, can't remember
> > the exact reasons right now...
> <snip>
>
> I would like to point out that reentrancy has absolutely nothing to do
> with this. Reentrancy is about one transaction accessing the
> same entity
> multiple times within the call stack. The problem we have here is with
> several transactions using one entity, which is different.
Sure...
I was thinking in the following terms, the A/B thing... c&p from the spec
An entity Bean Provider entity can specify that an entity bean is
non-reentrant. If an instance of a
non-reentrant entity bean executes a client request in a given transaction
context, and another request
with the same transaction context arrives for the same entity object, the
container will throw the
java.rmi.RemoteException to the second request. This rule allows the Bean
Provider to pro-gram
the entity bean as single-threaded, non-reentrant code.
The functionality of some entity beans may require loopbacks in the same
transaction context. An
example of a loopback is when the client calls entity object A, A calls
entity object B, and B calls back
A in the same transaction context. The entity bean's method invoked by the
loopback shares the current
execution context (which includes the transaction and security contexts)
with the Bean's method
invoked by the client.
If the entity bean is specified as non-reentrant in the deployment
descriptor, the Container must reject an
attempt to re-enter the instance via the entity bean's remote interface
while the instance is executing a
business method. (This can happen, for example, if the instance has invoked
another enterprise bean,
and the other enterprise bean tries to make a loopback call.) The container
must reject the loopback call
and throw the java.rmi.RemoteException to the caller. The container must
allow the call if the
Bean's deployment descriptor specifies that the entity bean is re-entrant.
Re-entrant entity beans must be programmed and used with great caution.
First, the Bean Provider must
code the entity bean with the anticipation of a loopback call. Second, since
the container cannot, in gen-eral,
tell a loopback from a concurrent call from a different client, the client
programmer must be careful
to avoid code that could lead to a concurrent call in the same transaction
context.
>
> regards,
> Rickard
>
> --
> Rickard Oberg
>
> Email: [EMAIL PROTECTED]
>
>
> --
> --------------------------------------------------------------
> To subscribe: [EMAIL PROTECTED]
> To unsubscribe: [EMAIL PROTECTED]
> Problems?: [EMAIL PROTECTED]
>
--
--------------------------------------------------------------
To subscribe: [EMAIL PROTECTED]
To unsubscribe: [EMAIL PROTECTED]
Problems?: [EMAIL PROTECTED]
