Partial Commit Entity EJB

Let's say I have an EJB session bean that runs for 10 minutes. During this time it tracks its progress by updating a percentage complete field for a particular row in a Process database table, via an EJB entity bean ProcessBean.

Problem is this: Commits for the Process table updates do not take place until after the 10 minutes has elapsed. In other words the user sees 0%, then after 10 minutes sees 100%. Is there a simple way to read the process data before the larger process has finished?

I have a few ideas but none that really sit well with me. I could force incremental commits of the entire transaction, but that would interfere with the transactional stability of the larger process. I could convert the CMP bean into BMP bean, although that seems like a waste of time. Finally, I could use a static object cache, but that seems like a bad idea since I'm essentially replicating the persistence cache.

How can a transaction last for 10 minutes?

Easily? It's spawned via an asynchronous MDB. I'll leave it up to your imagination to determine why you might need a long-running process.
[ May 29, 2008: Message edited by: Scott Selikoff ]

Indeed, that's my real question: why would a transaction last that long. I would question any EJB transaction which lasts for more than 30 seconds. If it does, then a redesign is probably needed.

What about using the "RequiresNew" transaction attribute on the method of the ProcessBean that updates the row? Your outer transaction would be suspended, a new transaction would be created, the row updated, the new transaction complete and commit the change, and your outer transaction would resume. This should make changes to that row visible outside the large outer transaction.

Originally posted by Roger Chung-Wee:
why would a transaction last that long. I would question any EJB transaction which lasts for more than 30 seconds. If it does, then a redesign is probably needed.

Again I'll leave it to your imagination.

For RequiresNew, that might work although my worry is that each time an update is performed a substantional overhead of suspending/resuming the main transaction might be incurred.

I think for now I'm going with a static object cache. It's easy enough to implement.