Hi all,
> + <para>
> + <![CDATA[<commit-option> must be A, B, C, D (after
2.2.1). ]]></para>
> + <para>Option A: The Container caches the bean between
transactions. This options assumes that the bean/container is the only one
accessing this data. Therefore, the container will never synchronize the
bean with the persistence storage, ejbStore/ejbLoad never get called.</para>
> + <para>Option B: The
Container caches the been between transactions. However, unlike option A
the container does not ensure exclusive access to the persitence storage.
Therefore, the container will synchronize at the beginning of each
transaction.</para>
> + <para>Option C: The
Contianer does not cache bean instances and instances are synchronized on
every transaction.</para>
> + <para>Option D: This is a
JBoss specific feature available in versions newer than the 2.2.1 release.
It enables a lazy write schema, where synchronization does happen but not
upon every transaction.
> + </para>
I think, this documentation is not fully correct and misleading
the reader. It should read similar to the following:
----- snip -----
<para>
<![CDATA[<commit-option> must be A, B, C, D (after 2.2.1). ]]></para>
<para>
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.</para>
<para>
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.</para>
<para>
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.</para>
<para>
Option D: This is a JBoss specific feature available in versions
newer than the 2.2.1 release. 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 5
seconds but you may configure the time (in seconds) with
<![CDATA[<optiond-refresh-rate>30</optiond-refresh-rate>]]>.</para>
<para>
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.</para>
<para>
A final note to executing business methods outside of a transaction
context: when reading the beans state you always must consider
the result as invalid and usable for rough display purposes only,
i.e. to fill in a large table, having benefit from bean caching (with
options A, B and D) and avoiding unneccessary concurrency; even with
commit option A, though you get the actual state initially, another
concurrent client might change the beans state a microsecond after
your read. Never write access a bean outside a transaction context
believing ejbStore will be called for synchronization, it typically
will not (though somtimes it might, when the container passivates
the bean) be called. Read the EJB specification 1.1 sections 9.1.7.1
and 11.6.3 carefully, if you plan to use the transaction attributes
Never, NotSupported or Supports.</para>
<para>
To safely write a bean depending on it's current state ever (re)read
and write the bean within one and the same transaction context.
</para>
----- snap -----
Migth someone with more code insight please validate that text?
Please note also, that english isn't my native language. If
this text is accepted, would somebody (gropi?) consider to
check it in?
Besides, in the current CVS main branch I couldn't find the
support for the D_COMMIT_OPTION, neither in ConfigurationMetaData.java
nor the new SoftBallInterceptor.
Best regards
Georg
___ ___
| + | |__ Georg Rehfeld Woltmanstr. 12 20097 Hamburg
|_|_\ |___ [EMAIL PROTECTED] +49 (40) 23 53 27 10
_______________________________________________
Jboss-development mailing list
[EMAIL PROTECTED]
http://lists.sourceforge.net/lists/listinfo/jboss-development
