[jboss-user] [JBossCache] - Re: TreeCache CacheLoader Issue

2007-05-16 Thread [EMAIL PROTECTED]
Node locking and concurrency is important to retain data integrity. Do you have a high percentage of writes? If so, then a caching library is NOT what you need. (think about it! :) If you want to use JBoss Cache as a distributed in-memory database, then I'd recommend using pessimistic locki

[jboss-user] [JBossCache] - Re: TreeCache CacheLoader Issue

2007-05-10 Thread robnor
Thank you! :-) View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4044636#4044636 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4044636 ___ jboss-user mailing list jboss-user@lists

[jboss-user] [JBossCache] - Re: TreeCache CacheLoader Issue

2007-05-10 Thread robnor
I tried to change this. I now have major problem with node locking errors. It seems it cannot cope with highfrequency updates? I have an Ojbect (ImportTracker) that holds multiple objects (BatchTracker). The ImportTracker holds all the BatchTrackers, the BatchTracker holds data about the imp

[jboss-user] [JBossCache] - Re: TreeCache CacheLoader Issue

2007-05-09 Thread [EMAIL PROTECTED]
Here's your problem: CacheHelper.getImportCache().get(nodename).put("importTracker", tracker); Use: CacheHelper.getImportCache().put(nodename, "importTracker", tracker); Do the same anywhere else you have the same kind of thing going on. The 1.x "public Node get(Fqn)" method was a bad idea and

[jboss-user] [JBossCache] - Re: TreeCache CacheLoader Issue

2007-05-09 Thread robnor
I used fisheeye recommended-config.xml and modified it for my purposes. I have checked out alternative configurations with evictionrules etc, but they still does not trigger the store interceptor, thus leaving the persistant state and the in-memory state inconsistent with eachother. I am stil

[jboss-user] [JBossCache] - Re: TreeCache CacheLoader Issue

2007-05-09 Thread genman
I didn't really dig into your specific issue, but I do have some general advice. Regarding persistence, there are some bundled configurations that use cache loaders. You can try to use these as a "sanity check". These configurations are unit tested and should work. Check out the unit tests for

[jboss-user] [JBossCache] - Re: TreeCache CacheLoader Issue

2007-05-08 Thread robnor
Hmm.. no replies :-) I suppose that this could be a bug in jboss as aop implementation that does not trigger interceptor as it should. It could also be that treecache bug where the pointcut definition is not correct. Then of course it could be me that has used treecache in the wrong way... (O

[jboss-user] [JBossCache] - Re: TreeCache CacheLoader Issue

2007-05-08 Thread robnor
My current workaround: | public static void storeTracker(ImportTracker tracker) | { | logDebug("storeTracker() - start"); | | try | { | if (useTreeCache) | { | logDebug("ImportTracker - PUT"); | boolean transactionActive = false

[jboss-user] [JBossCache] - Re: TreeCache CacheLoader Issue

2007-05-08 Thread robnor
Further Cache config: | | jboss:service=Naming | jboss:service=TransactionManager | jboss.jca:service=DataSourceBinding,name=DefaultDS _ | | | | org.jboss.cache.JBossTransactionManagerLookup | OPTIMISTIC | REPEATA

[jboss-user] [JBossCache] - Re: TreeCache CacheLoader Issue

2007-05-08 Thread robnor
Log: | 2007-05-08 11:33:40,093 DEBUG [ImportCacheHelper] storeTracker() - start | 2007-05-08 11:33:40,093 DEBUG [ImportCacheHelper] ImportTracker - PUT | 2007-05-08 11:33:40,093 DEBUG [ImportCacheHelper] TRANSACTION STATUS: Active [0] | 2007-05-08 11:33:40,093 DEBUG [TxInterceptor] loca