ignoring write lock acquisition failure

[sebblind]

Hi,
I am trying to use tree cache as the second level cache for an application that uses hibernate 3.2.5 on weblogic 3.2.5. I've upgraded to jbosscache 1.4.1 sp4 and jgroups2.4.1.

I guess I have a configuration problem somewhere. When I use EhCache (non clustered), it works fine and I see the second level getting populated (using hibernate statistics). With my current jbosscache configuration, I get some "ignoring write lock acquisition failure" error message every time hibernate tries to put something in the cache, and nothing gets in in the end. I have tried to deploy this on a windows and unix boxes without any difference.

I am not sure how to proceed from here. any help would be appreciated!

Thanks,
Sebastien

Debug Logs
2007-08-09 10:31:05,931 DEBUG [TwoPhaseLoad] ([ACTIVE] ExecuteThread: '0' for queue: 'weblogic.kernel.Default (self-tuning)') resolving associations for [com.xxx.domain.attribute.AttributeDataType#CHECKLISTITEM]
2007-08-09 10:31:05,931 DEBUG [TwoPhaseLoad] ([ACTIVE] ExecuteThread: '0' for queue: 'weblogic.kernel.Default (self-tuning)') adding entity to second-level cache: [com.xxx.domain.attribute.AttributeDataType#CHECKLISTITEM]
2007-08-09 10:31:05,931 DEBUG [TransactionalCache] ([ACTIVE] ExecuteThread: '0' for queue: 'weblogic.kernel.Default (self-tuning)') caching: com.xxx.domain.attribute.AttributeDataType#CHECKLISTITEM
2007-08-09 10:31:05,931 DEBUG [TreeCache] ([ACTIVE] ExecuteThread: '0' for queue: 'weblogic.kernel.Default (self-tuning)') ignoring write lock acquisition failure
2007-08-09 10:31:05,931 DEBUG [TwoPhaseLoad] ([ACTIVE] ExecuteThread: '0' for queue: 'weblogic.kernel.Default (self-tuning)') done materializing entity [com.xxx.domain.attribute.AttributeDataType#CHECKLISTITEM]

configuration files: All the app xml files can be found at:
http://forum.hibernate.org/viewtopic.php?t=978360

[manik]

This happens when hibernate tries to put an entry in the cache but this put has to block for some other reason (a concurrent put). In this case one of the puts will ignore the lock acquisition failure and not bother to cache the entity since another thread may be doing the same thing.

[sebblind]

thanks for the reply. I have a single-threaded client that calls a getdata method on the server side which basically does a select via hibernate. where could the concurrency come from?