Note the following regarding NotSupported:
<ejb 2.0PDF2 spec>
12.1.6.1 ejbLoad and ejbStore with the NotSupported transaction attribute
The use of the ejbLoad and ejbStore methods for caching
an entity object's state in the instance works well only if the
Container can use transaction boundaries to drive the ejbLoad and
ejbStore methods. When the NotSupported[23] transaction attribute is
assigned to a component interface method, the corresponding enterprise
bean class method executes with an unspecified transaction context
(See Subsection 17.6.5). This means that the Container does not have
any well-defined transaction boundaries to drive the ejbLoad and
ejbStore methods on the instance.
Therefore, the ejbLoad and ejbStore methods are "unreliable" for the
instances that the Container uses to dispatch the methods with an
unspecified transaction context. The following are the only guarantees
that the Container provides for the instances that execute the methods with
an unspecified transaction context:
. The Container invokes at least one ejbLoad between ejbActivate and the
first business method in the instance.
. The Container invokes at least one ejbStore between the last business
method on the instance and the ejbPassivate method.
Because the entity object's state accessed between the ejbLoad and
ejbStore method pair is not protected by a transaction boundary for the
methods that execute with an unspecified transaction context,
the Bean Provider should not attempt to use the ejbLoad and ejbStore
methods to control caching of the entity object's state in the instance.
Typically, the implementation of the ejbLoad and ejbStore methods should
be a no-op (i.e., an empty method), and each business method should
access the entity object's state directly in the database.
</ejb 2.0PDF2 spec>
----- Original Message -----
From: Scott M Stark
To: [EMAIL PROTECTED]
Sent: Thursday, August 02, 2001 11:38 PM
Subject: Re: [JBoss-user] transactions and isModified method
You can declare an entity bean to use TX_NOT_SUPPORTED, and
with commit option B this effectively creates a read only cache. Even
if B is the not commit option you should be able to avoid the pessimistic
locking on the transaction. You have to be sure that this is the correct
semantics though.
>yes I'm getting a timeout at the app level. everything works fine with a
>single thread, no deadlock
>but as soon as I introduce two threads then deadlock happens everywhere.
the
>thing is that all of the methods are get( readonly)
>so why would I deadlock. why can't I just get my value from the entity bean
>and move on?
>
>or maybe it's the finders that are making all the fuss...
>
>-dom
_______________________________________________
JBoss-user mailing list
[EMAIL PROTECTED]
http://lists.sourceforge.net/lists/listinfo/jboss-user
_______________________________________________
JBoss-user mailing list
[EMAIL PROTECTED]
http://lists.sourceforge.net/lists/listinfo/jboss-user
