"floefliep" wrote : The insert warning: it no longer occurs since writeLoad() no longer passes in a previousVersion=null Perhaps that is the reasoning. But my experience was that this scenario was actually previously caused by this "(re)validate in any subsequent transaction(s)" check in most cases and that it was much more the "if ( this == dataVersion )" check that stopped the exceptions. But either way...
"floefliep" wrote : query-cache-0.6-second gapFirst, I was wrong about .6 seconds as I forgot a division of the timestamp by 100 in my manual calculation. This basically comes from o.h.c.UpdateTimestampsCache. This is responsible for deciding whether or not cached query results should be considered invalid; it does this through some timestamping. Whenever Hibernate performs DML operations against a set of "table spaces", it notifies the UpdateTimestampsCache in a two phase process (preinvalidate and invalidate). invalidate() is responsible for setting the appropriate timetamp value into the underlying cache region that is then later used in the isUpToDate() checks. However, that invalidate() call happens during Hibernate's after-transaction-completion process. Which of course fails when using TreeCache because it does not like this put() outside the scope of an active transaction. And basically this all means that query caching is totally useless here. "floefliep" wrote : CMT edge case For example, in my tests, it creeps up in trying to clean up the test data. Consider: | s = openSession(); | s.delete( item ); | where item is a detached instance and where we are relying on flush-on-completion with CMT. In this case, Hibernate has made no TreeCache calls and thus TreeCache has not had a chance to register its synchronization. Now, at transaction commit Hibernate's synchronization gets a beforeCompletion callback and starts its flush processing; at that point it now calls into TreeCache which causes TreeCache to register its synch - but that is obviously too late in the game since because it registers in the midst of the beforeCompletion phase it will (at least) not get a "floefliep" wrote : Weird validated node in next transaction In my experience, it *appears* that it does not matter if you even access the node at all... But I need to verify this some more. "floefliep" wrote : I replaced in your latest OptimisticTreeCache: So I am missing something. You mean to tell me that TreeCache.remove() *fails* if the node does not exist even when you explicitly specify "fail silently"? I needed the "protection check" in OptimisitcTreeCache.remove() because there I cannot explcitly set the fail-silectly mode... "floefliep" wrote : Exceptions all over the place Other than whats discussed above? What are they? View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3957727#3957727 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3957727 _______________________________________________ jboss-user mailing list jboss-user@lists.jboss.org https://lists.jboss.org/mailman/listinfo/jboss-user
