There's been a bit of chat about that recently on the list. If you have non
JBoss modification of your persistence, you'll probably want to use commit
option B or C for entity beans. Commit option A assumes exclusive access to
persistence.
Using commit options B/C isn't quite as speedy as A. I
Oh, and for info about commit options, see the jboss.xml dtd
http://www.jboss.org/documentation/jboss.dtd
Mike
On (09/05/01 16:52), Rafael Alves Chaves wrote:
>
> > The ejbCreate method or postCreate of Documento must insure that all the beans
> > properties are set.
>
> Thanks, Victor, this w
Rafael,
You'll want to use commit options B or C for your entity beans. See the EJB 1.1 spec
section 9.1.10 for definitions.
You define the commit option using the element in jboss.xml.
--Victor
Rafael Alves Chaves wrote:
>
> If I have a legacy application changing the database concurrently
> The ejbCreate method or postCreate of Documento must insure that all the beans
> properties are set.
Thanks, Victor, this was my fault.
> There is no need for the container to call ejbFindByPrimaryKey if the bean is
> already in the container's cache.
If I have a legacy application changin
The ejbCreate method or postCreate of Documento must insure that all the beans
properties are set.
There is no need for the container to call ejbFindByPrimaryKey if the bean is
already in the container's cache. And if you're using commit option A the
container will not call ejbLoad in your exampl
Hi,
I'm having a strange problem with entity beans in JBoss. For debugging
purposes, I have instrumented ALL callback and business methods to
generate an output identifying the called method and, when useful, its
arguments.
Below is the trace generated after two different clients are execu
