Dear developers,
a week ago I tried to contribute some lines of documentation,
since then I got no response at all, neither a flat denial, nor
corrections nor an OK, so I assume the message got lost/overlooked.
May I again ask someone to look over the text and if it's
OK to check it in?
Thanks
Georg
___ ___
| + | |__ Georg Rehfeld Woltmanstr. 12 20097 Hamburg
|_|_\ |___ [EMAIL PROTECTED] +49 (40) 23 53 27 10
----- Original Message -----
From: "Georg Rehfeld" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Saturday, May 19, 2001 12:34 AM
Subject: Re: [JBoss-dev] CVS update: manual/src/docs advconfig.xml
> 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
