Yeah. Most places I do this... But, for this one instance it makes more sense from a performance and time to program sense to use a sql query. Basically, when one bean changes, the session bean updates the state of a summary table based on the state of that one bean, plus several other tables... Its just faster/easier for me to do the query in the database. As a side note, I've figured out how to phrase my query in a way that ignores the fact that the database hasn't been updated yet, and gives me the result I want... But it seems to me that the ability to checkpoint a transaction would be an awful nice addition to the spec... Basically, what should happen is that the bean should write to the database, but not commit the transaction when checkpoint on the transaction object is called. This would allow for situations where ORM doesnt make the most amount of sense, but still allow EJB and its transactional model to be very useful... Then if the transaction succeeds the write remains, otherwise the database will have to rollback... thanx, -gabe Chris Raber wrote: > Nope. EJB's transaction model is "flat". > > It occurs to me, why doesn't the session bean query the entity bean instead > of querying the underlying table directly? That way the entity bean can > answer from its cached state instead of relying on the underlying table as > the communication mechanism! > > -Chris.
begin: vcard fn: Gabriel Lawrence n: Lawrence;Gabriel org: Kovair<br>The power to .wow your customers. adr: 2 North First Street ;;Suite 212;San Jose;Ca;95113-1202;USA email;internet: [EMAIL PROTECTED] title: Architect tel;work: (408) 491-9731 note: The power to .wow your customers. x-mozilla-cpt: ;0 x-mozilla-html: FALSE version: 2.1 end: vcard
