Sorry for my late reply, been too busy yesterday.
anonymous wrote : 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
"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 c
Exceptions all over the place, must be my lucky day!;) (today is the
13th after all...)
Fortunately for one part it seems a simple beauty fixup, I replaced in your
latest OptimisticTreeCache:
| public void writeLoad(Object key, Object value, Object currentVersion) {
|
| //$Id: OptimisticTreeCache.java 9965 2006-05-30 13:00:28 -0500 (Tue, 30 May
2006) [EMAIL PROTECTED] $
| package org.hibernate.cache;
|
| import java.util.HashMap;
| import java.util.Iterator;
| import java.util.Map;
| import java.util.Set;
| import java.util.Comparator;
|
So if you could, I can post here the latest changes I have made to the
o.h.c.OptimisticTreeCache class for you to verify. It should fix the vast
majority of the issue you were seeing. There are still some "transactionality
mismatch" (for lack of a better term) issues Hibernate and JBoss Cache
I have some local mosds to these tests...
I just confirmed with Manik regarding the mixing of calls supplying and calls
not supplying a data-version. Hibernate will need to provided data-version
info for all nodes under its control reagrdless of whether optimistically
locking these nodes makes
Just checked out the latest Hibernate source from
http://anonhibernate.labs.jboss.com/trunk/Hibernate3, but I can't find a method
testNoVersioningProvided() in there ... where should this be included?
Anyway, my guess is still remains: TreeCache doesn't work fine if you mix
non-versioning and
More news:
It seems it is happening with the query cache enabled, since at the location of
the exception the toString() of workspaceNode is:
WorkNode fqn=/org/hibernate/cache/StandardQueryCache dirty ver=null
When I disable the query cache, I get another similar exception:
Caused by: java.lang
Here is the test to which I refer, which works (from the Hibernate test suite):
| public void testNoVersioningProvided() throws Throwable {
| // note : mimic query cache interactions...
| Fqn fqn = Fqn.fromString( "org/hibernate/querycache" );
| Tree
Well, no luck. I replaced OptimisticTreeCache with the latest version from CVS,
which, as I understood from reading HHH-1796 at least, should fix the problem
using a new Fqn.
I've been debugging and browsing code for hours now trying to figure out what
is going on and I think problem is twofold
My guess is that you are seeing a manifestation of
http://opensource.atlassian.com/projects/hibernate/browse/HHH-1796
There is absolutely no way that Hibernate would apply a DataVersion to a *query
cache* region, as they logically should have no versioning info at all. Thus
we use null DataVer
as for your point #2, the *only* time a call should ever get routed through
writeLoad() with a null source is a collection cache. There is a hole in our
test suite regarding optimistic caches in conjunction with collection caches
because I had not intended to apply optimisitc locking to the col
I'll dig into this further tomorrow.
But just by quickly looking at the test case you mention, and according to what
I saw TreeCache doing today, that test may pass since it only seems to deal
with non-versioning stuff within a transaction. But that might not be the case
when running for real,
Clarification to my previous post:
As for point 2, yes, I confirm, source==null happened in a case where a cached
collection was loading (or being put into; don't remember) from its collection
cache.
View the original post :
http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3957164#3957
Now, Hibernate is currently bundling an older version of TreeCache. Perhaps
something changed in newer versions which caused this to start failing
View the original post :
http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3957102#3957102
Reply to the post :
http://www.jboss.com/index.h
15 matches
Mail list logo
