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=osdntextlink _______________________________________________ JBoss-user mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-user
