That seems to be your problem yes. If the db is touched from outside the JBoss then
you have to have a more suitable commit option than the default one. To see if it
works, edit your conf/standardjboss.xml and change commit options from A to B (search
for this row: <commit-option>A</commit-option>) and restart your JBoss and test again..
Also see this page for more info: http://www.jboss.org/documentation/HTML/ch06s08.html
Here is a clip from it:
<commit-option> must be A, B, C, D (in CVS version).
Option A: The container caches the beans state between transactions. This options
assumes that the bean/container is the only one accessing the persistent data.
Therefore the container synchronizes the memory state from the persistent storage only
(via ejbLoad) when absolutely neccessary (when the state isn't cached yet), that is
before the first business method executes on a found bean or after the bean is
passivated and reactivated to serve another business method. This behaviour is
regardless of wether the business method executes inside or outside a transaction.
Option B: The container caches the bean between transactions. However, unlike option A
the container does not have exclusive access to the persistent storage. Therefore, the
container will synchronize the memory state (via ejbLoad) at the beginning of each
transaction. Thus business methods executing in a transaction context don't see much
benefit from the container caching the bean, whereas business methods executing
outside a transaction context (transaction attributes Never, NotSupported or Supports)
access the cached (and invalid) state of the bean.
Option C: The container does not cache bean instances and instances memory state is
synchronized on every transaction start (via ejbLoad). For business methods executing
outside a transaction the synchronization is done too, but as the ejbLoad executes in
the same transaction context as the triggering business method, the state must still
be considered invalid and might already have changed in the persistent storage when
the business method executes.
Option D: This is a JBoss specific feature available in the actual version from CVS
only. It enables a lazy read schema, where the beans state is cached between
transactions as with option A, but resynchronized from the persistent storage from
time to time (via ejbLoad). The default time between resynchronizations is 30 seconds
but you may configure the time (in seconds) with
<optiond-refresh-rate>42</optiond-refresh-rate>.
With all four commit options the container must synchronize the bean instances cached
state with the persistent storage (via ejbStore) at the end of each transaction (just
before a commit is done) to be sure the whole transactions state is consistently
persistet. As of the EJB specification there is no safe way for the container to
decide, if the beans state actually has changed since transaction start, so ejbStore
is called, even when all access to the beans business methods was read only. Note,
however, that JBoss supports an optional method public boolean isModified() in the
beans implementation. If this method returns false, the call to ejbStore is skipped at
commit time.
/Lennart
----- Original Message -----
From: Lau Chet Hong <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Wednesday, June 20, 2001 4:48 AM
Subject: RE: [JBoss-user] Weird problem with transaction - more info for questions
> Lennart,
> I think I found out the reason being that:
> After the first time I run the client to update the record, and before I run
> it the second time, I did open up the table manually (through the DBMS) to
> delete the record. Somehow if I delete the record manually, the client will
> throw the error if it tries to update the same record the second time, which
> is now, non-existent. Seems like jBoss is still keeping reference or cache
> to that record. I'm still new to this, and don't really know what's in jBoss
> design, so this is only my guess. Anyone can enlighten me on this ? Thanks!
>
> ChetHong
>
>
_______________________________________________
JBoss-user mailing list
[EMAIL PROTECTED]
http://lists.sourceforge.net/lists/listinfo/jboss-user
