User: gropi
Date: 01/05/28 06:49:56
Modified: src/docs advconfig.xml
Log:
Clarifications for the commit-option by Georg Rehfeld (thanks).
Revision Changes Path
1.10 +68 -7 manual/src/docs/advconfig.xml
Index: advconfig.xml
===================================================================
RCS file: /cvsroot/jboss/manual/src/docs/advconfig.xml,v
retrieving revision 1.9
retrieving revision 1.10
diff -u -r1.9 -r1.10
--- advconfig.xml 2001/05/22 06:28:05 1.9
+++ advconfig.xml 2001/05/28 13:49:56 1.10
@@ -470,13 +470,74 @@
]]></para>
</listitem>
<listitem>
- <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>
+<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>
</listitem>
</itemizedlist>
</section>
_______________________________________________
Jboss-development mailing list
[EMAIL PROTECTED]
http://lists.sourceforge.net/lists/listinfo/jboss-development
