is there any reason to be concerned that the application code for EntityFolder basically caches its own copies of LocalMessage entity beans while a folder is open? or is there any reason to be concerned that it maintains its own ad-hock transactions in the form of locking/unlocking and committing?
i'm a bit concerned, but am still thinking it over as to exactly why. i've learned that two caches can sometimes work at odds with each other, and lead to all sorts of standard concurrency problems that one tries to avoid by using j2ee app servers in the first place. here, jboss CMP maintains its own cache, as does our application code in EntityFolder, and the two do not communicate. also, shouldn't any transactional stuff be done in the context of jboss's transaction manager? i know someone was probably thinking that folders stay open too long to involve them in real transactions, but is there another way to do it than manage an ad-hoc transaction within EntityFolder? it seems like the ad-hoc transaction basically only involves a possible deletion of several emails at the moment, which may be a mitigating factor for now.
Well "transaction" doesn't always mean the same thing. The POP transaction is really just a matter of state. I haven't looked real close at Eric's entity folder code though. It could be wrong. Take a look and do what you think is best. I trust your judgement. Plus I trust CVS to fix any errors in your judgement ;-)