I did miss this one. The big difference between B and C is that B can store resources in the bean implementation between transactions. In C the container always discards the instance at the end of the transaction. Option B also has the big advantage that at the start of the next transaction the container only has to synchronize the data with the database. JBoss currently does not take advantage of this, but in a future release the container will just check if the row has changed since it was last loaded (using a last update serial number or timestamp).
-dain Jeff Schnitzer wrote: > Just in case this was missed the first time around, thought I would > repost and summarize: > > What commit options are supported by JBoss 3.0 CMP? Without bean access > outside of a transaction, I'm really puzzled by the difference between > options B and C. I'd really like to use the JBoss bean cache, but as it > currently stands this doesn't seem possible. > > (read below for the details) > > Thanks, > Jeff Schnitzer > [EMAIL PROTECTED] > > >>-----Original Message----- >>From: Jeff Schnitzer >>Sent: Thursday, June 13, 2002 6:27 PM >>To: [EMAIL PROTECTED] >>Subject: RE: [JBoss-user] Calling entity outside of TX >> >> >>>From: Dain Sundstrom [mailto:[EMAIL PROTECTED]] >>> >>>You must have a transaction. The spec suggests this requirement, >> > but > >>>allows a way out if I wanted to support it. It is on the todo list >> > to > >>>support read-only entities without transactions, but I'm not sure if >> > I > >>>want to add support. I really don't understand why you would not >> > want > >>a >> >>>transaction (they have immeasurable over head in JBoss). If you are >>>worried about long running transactions just use requires new. >> >>If you cannot read entities outside of a transaction, then what is the >>practical difference between Commit Option B and Commit Option C? In >>both cases, the beans must be loaded from the database at the > > beginning > >>of a transaction. It seems like the extra caching of Option B is a >>waste. >> >>My reason for wanting bean access outside of a transaction is to make >>use of entity caching. I have an application with these >>characteristics: >> >>. Most bean access can tolerate stale data (read-only, of course) >>. Some bean access must have valid, transactional data >> >>I'm not trying to avoid the overhead of a transaction, I'm trying to >>avoid the overhead of a database hit. Up till now I have been caching >>EJB data myself as data objects. When I saw the JBoss documentation > > for > >>Commit Option B > > (http://www.jboss.org/online-manual/HTML/ch07s16.html), > >>I figured that it's silly for me to cache myself when JBoss is already >>doing it for me. It seemed simple, "Required" for valid data, >>"Supports" for cached (but stale) data. >> >>Obviously those docs must apply to JBoss prior to 3.0 :-( >> >>Is this a compelling reason to add read-only access to entities > > outside > >>of a transaction, or should I go back to manual caching? >> >>It should be noted that this application is destined to be clustered, > > so > >>Commit Option A isn't really an option. >> >>Thanks, >>Jeff Schnitzer >>[EMAIL PROTECTED] > > > > _______________________________________________________________ > > Don't miss the 2002 Sprint PCS Application Developer's Conference > August 25-28 in Las Vegas - >http://devcon.sprintpcs.com/adp/index.cfm?source=dntextlink > > _______________________________________________ > JBoss-user mailing list > [EMAIL PROTECTED] > https://lists.sourceforge.net/lists/listinfo/jboss-user _______________________________________________________________ Don't miss the 2002 Sprint PCS Application Developer's Conference August 25-28 in Las Vegas - http://devcon.sprintpcs.com/adp/index.cfm?source=osdntextlink _______________________________________________ JBoss-user mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-user
