Heath. Thanks for the response. In rare cases, our code is doing what you've described, and I was able to recreate by forcing this rare case:
1. A transaction is started and committed w/o any changes occurring. 2. When commit is called, we have multiple TransactionListeners that are fired, and one of them does end up making a change in rare cases. I've coded up a workaround where we always dirty a transaction before calling commit, but I'm a little worried about the extra overhead this would cause. Regardless, we're too late in our development cycle to get this change into our product, so we'll probably have to live with this until our next patch, where hopefully we'll be able to pull in an OpenJPA fix for this. I think we're in agreement that this is a valid OpenJPA bug. Has a JIRA issue been opened for this yet? Thanks! -- View this message in context: http://openjpa.208410.n2.nabble.com/UnsupportedOperationException-from-BrokerImpl-flushTransAdditions-BrokerImpl-java-2099-using-OpenJPA2-tp5000485p5019958.html Sent from the OpenJPA Users mailing list archive at Nabble.com.
