[Hibernate-JIRA] Created: (HHH-3220) Patch to prevent "org.hibernate.AssertionFailure: possible non-threadsafe access to the session" error caused by stateless sessions
by Dan Bisalputra (JIRA)
Patch to prevent "org.hibernate.AssertionFailure: possible non-threadsafe access to the session" error caused by stateless sessions
-----------------------------------------------------------------------------------------------------------------------------------
Key: HHH-3220
URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-3220
Project: Hibernate3
Issue Type: Patch
Components: core
Affects Versions: 3.2.6
Environment: Hibernate 3.2.6, Apache Derby on Mac OSX & PC
Reporter: Dan Bisalputra
Priority: Minor
When performing a query in a stateless session, the query loads objects in a two-phase process in which a temporary persistence context is populated with empty objects in the first phase, then the objects' member data are read from the database in the second phase. If one of the objects contains an association or a collection, it performs a recursive call to the session's get() method. The get() method clears the temporary persistence context, so if the parent object contains any other associations to be read in the second phase, Hibernate throws an assertion because they are not found in the persistence context.
This patch solves the problem by only clearing the persistence context when the recursion ends. It passes all the unit tests for our application, but I have not tested it with any of the Hibernate unit tests.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://opensource.atlassian.com/projects/hibernate/secure/Administrators....
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
14 years, 4 months
[Hibernate-JIRA] Created: (HHH-3637) Union in where doesn't works for Sybase, need to evict test case
by Juraci Paixao Krohling (JIRA)
Union in where doesn't works for Sybase, need to evict test case
----------------------------------------------------------------
Key: HHH-3637
URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-3637
Project: Hibernate Core
Issue Type: Improvement
Components: testsuite
Environment: Sybase ASE 15.0.2
Reporter: Juraci Paixao Krohling
Assignee: Juraci Paixao Krohling
It seems that Sybase doesn't supports UNION inside WHERE clauses, causing the test DynamicFilterTest#testSqlSyntaxOfFiltersWithUnions to fail. The scenario for this test case is not described in the documentation, but I would expect it to work:
http://infocenter.sybase.com/help/index.jsp?topic=/com.sybase.infocenter....
The query is:
select
category0_.CAT_ID as CAT1_6_,
category0_.name as name6_,
category0_.eff_start_dt as eff3_6_,
category0_.eff_end_dt as eff4_6_
from
CATEGORY category0_
where
'abc' in (
select
d.reg
from
department d
where
(
d.dept_id=123
)
union
select
p.name
from
sales_person p
)
If executed only the queries from inside the where clause (the two selects with union), it works as expected. Also, if removed the union and one of the queries inside the where, it works as expected. So, the problem happens only when using union inside a where clause.
For now, I'd suggest to evict this test for Sybase.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://opensource.atlassian.com/projects/hibernate/secure/Administrators....
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
14 years, 4 months
[Hibernate-JIRA] Created: (HHH-2447) Connection leak if logAndClearWarnings throws
by Jeppe N. Madsen (JIRA)
Connection leak if logAndClearWarnings throws
----------------------------------------------
Key: HHH-2447
URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-2447
Project: Hibernate3
Type: Bug
Components: core
Versions: 3.1.3, 3.2.2
Environment: Database product name : DB2/NT
Database product version : SQL08025
JDBC driver name : IBM DB2 JDBC Universal Driver Architecture
Hibernate 3.1.3 (seems to exist in 3.2.2 as well)
JDBC driver version : 2.9.31
Reporter: Jeppe N. Madsen
Priority: Minor
In ConnectionManager.closeConnection, logAndClearWarnings is called before connection.close() is called. If this call throws an exception, the connection is never closed.
We have observed that DB2 sometimes throws an Error because the SQLWarning chain is wrong:
[14-02-07 11:36:30:889 CET] 10b0b533 WebGroup E SRVE0026E: [Servlet Error]-[SQLWarning chain holds value that is not a SQLWarning]: java.lang.Error: SQLWarning chain holds value that is not a SQLWarning
at java.sql.SQLWarning.getNextWarning(SQLWarning.java:109)
at org.hibernate.util.JDBCExceptionReporter.logWarnings(JDBCExceptionReporter.java:50)
at org.hibernate.util.JDBCExceptionReporter.logWarnings(JDBCExceptionReporter.java:33)
at org.hibernate.util.JDBCExceptionReporter.logAndClearWarnings(JDBCExceptionReporter.java:22)
at org.hibernate.jdbc.ConnectionManager.closeConnection(ConnectionManager.java:443)
at org.hibernate.jdbc.ConnectionManager.cleanup(ConnectionManager.java:379)
at org.hibernate.jdbc.ConnectionManager.close(ConnectionManager.java:318)
at org.hibernate.impl.SessionImpl.close(SessionImpl.java:293)
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://opensource.atlassian.com/projects/hibernate/secure/Administrators....
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
14 years, 4 months
[Hibernate-JIRA] Created: (HHH-4015) one-to-one: foreign key: save Problem
by Sandeep Vaid (JIRA)
one-to-one: foreign key: save Problem
-------------------------------------
Key: HHH-4015
URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-4015
Project: Hibernate Core
Issue Type: Bug
Components: core
Affects Versions: 3.2.6
Reporter: Sandeep Vaid
Priority: Critical
I have one-to-one relationship between class A and class B
<class name="A" table="TEMPA" >
<id name="aaId" type="string" column="AID" length="10">
<generator class="assigned"></generator>
</id>
<one-to-one name="b" class="B" constrained="true" outer-join="false" cascade="save-update" />
</class>
<class name="B" table="TEMPB" lazy="true">
<id name="baId" type="string" column="BID" length="10">
<generator class="foreign">
<param name="property">a</param>
</generator>
</id>
<one-to-one name="a" class="A" />
</class>
Problem 1: When i try to save A, it fires :
insert into HBLEARN1.TEMPB (BID) values ('1')
and throws error :
The insert or update value of the FOREIGN KEY "TEMPB.CC1246876555824" is not equal to any value of the
parent key of the parent table. SQLSTATE=23503
Why it is first trying to save 'B' instead of 'A' first ?
Problem 2: With this mapping, if i set <property name="hibernate.hbm2ddl.auto">create</property> in hibernate.cfg.xml,
It generates TEMPA whose aaId is the foreign key referencing TEMPB. This is also incorrect..
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://opensource.atlassian.com/projects/hibernate/secure/Administrators....
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
14 years, 4 months
[Hibernate-JIRA] Created: (HHH-2075) many-to-one in a properties element causes strange PropertyValueException on flush
by Josh Moore (JIRA)
many-to-one in a properties element causes strange PropertyValueException on flush
----------------------------------------------------------------------------------
Key: HHH-2075
URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-2075
Project: Hibernate3
Type: Bug
Components: core
Versions: 3.2.0.cr4
Environment: HSQLDB
Hibernate r10478
Reporter: Josh Moore
Attachments: exception.txt, log.txt, properties.zip
Full test directory zip (org/hibernate/test/properties) attached. But to summarize, the following test will fail on flush after a simple merge. The exception thrown says that Pixels.sizeC is null -- though it's clearly set in the test case.
<code>
Image i = new Image();
Pixels p = new Pixels();
p.setSizeC(new Integer(2));
p.setImage(i); // This calls i.getPixels().add(p)
// i.setPixels(null); // This makes it work.
Session s = openSession();
Transaction t = s.beginTransaction();
// s.merge(i); // This makes it work.
p = (Pixels) s.merge(p); // This fails with the exception below.
t.commit();
s.close();
</code>
The properties element in question is:
<code>
<properties name="defaultPixelsTag">
<property name="defaultPixels" type="java.lang.Boolean"/>
<many-to-one name="image" class="Image" column="image"
not-null="true" unique="false" insert="true" update="true"
cascade="lock,merge,persist,replicate,refresh,save-update"
/>
</properties>
</code>
The reverse side is:
<code>
<set
name="pixels"
lazy="true"
inverse="true"
cascade="lock,merge,persist,replicate,refresh,save-update">
<key column="image" not-null="false"/>
<one-to-many class="Pixels"/>
</set>
</code>
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://opensource.atlassian.com/projects/hibernate/secure/Administrators....
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
14 years, 4 months
[Hibernate-JIRA] Created: (HHH-3102) Cascading ManyToOne collections do not eagerly set identifiers on saveOrUpdate()
by Paul Cowan (JIRA)
Cascading ManyToOne collections do not eagerly set identifiers on saveOrUpdate()
--------------------------------------------------------------------------------
Key: HHH-3102
URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-3102
Project: Hibernate3
Issue Type: Bug
Components: core
Affects Versions: 3.2.4.sp1
Reporter: Paul Cowan
Priority: Minor
Attachments: HibernateKeyPoolTest.java
Hi all,
Not 100% sure if you'd call this a 'bug' as I'm not sure if the correct behaviour is actually specified anywhere. It's certainly oddly inconsistent though.
Please find attached a standalone test case (requires HSQLDB on the classpath; amend setUp() if you need to use something else) which models a parent-child mapping between 'Mouth' (1) and 'Teeth' (many). The Mouth -> Teeth relationship is bidirectional, with CascadeType.ALL on the single-valued end. Both Mouth and Tooth use a @GenericGenerator, which simply allocates integers from a static keypool.
A mouth with one tooth is created, saveOrUpdate()d, session is flushed, a new tooth is added, mouth is saveOrUpdate()d again, and session is again flushed. The debug output is as follows:
*** After creation
Mouth (id=null) has teeth [canine(id=null)]
*** Save
Mouth (id=1) has teeth [canine(id=2)]
*** Flush
Hibernate: insert into Mouth (id) values (?)
Hibernate: insert into Tooth (mouthId, name, id) values (?, ?, ?)
Mouth (id=1) has teeth [canine(id=2)]
*** Add new
Mouth (id=1) has teeth [canine(id=2), molar(id=null)]
*** Save again
Mouth (id=1) has teeth [canine(id=2), molar(id=null)]
*** Flush again
Hibernate: insert into Tooth (mouthId, name, id) values (?, ?, ?)
Mouth (id=1) has teeth [canine(id=2), molar(id=3)]
As you can see, when initially created the IDs for the mouth and tooth are both null (obviously correct). The saveOrUpdate() on the Mouth object then generates identifier values, even though no DB write has been done yet (the .flush()). So far, so good.
However, when a NEW transient Tooth instance ("molar") is added to the Mouth, and saveOrUpdate() is called once more, the id generator is not invoked, UNTIL such time as the session is flushed.
While I guess it's fine for an object in the 'persistent' state not to actually have an identifier until flush-time (e.g. when using DB-side IDENTITY-type generation), it just seems inconsistent that with a @GenericGenerator the behaviour would vary depending on whether the PARENT object was already persistent or not.
There are some obvious workarounds (e.g. flush the session upon saving, or save the child entity first independently) but I thought I'd clarify if this behaviour is by design or not and suggest that this be made consistent.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://opensource.atlassian.com/projects/hibernate/secure/Administrators....
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
14 years, 4 months
[Hibernate-JIRA] Created: (HHH-2166) Long "in" lists in queries results in a Java stack overflow exception.
by Philip R. "Pib" Burns (JIRA)
Long "in" lists in queries results in a Java stack overflow exception.
----------------------------------------------------------------------
Key: HHH-2166
URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-2166
Project: Hibernate3
Type: Bug
Components: core
Versions: 3.2.0.ga
Environment: Hibernate 3.2.0.cr3 through 3.2.0.ga (at least). Any standard deployment of Sun's JVM on Windows, Linux, or Mac OS X (and presumably other platforms like Solaris)
Reporter: Philip R. "Pib" Burns
Attachments: NodeTraverser.java
With Hibernate 320ga a long "in" list can result in a stack overflow error during the parsing stage. For example, a query element like
where x in (:x)
or a manually constructed
where x in (1,2,3 .....)
can generate a stack overflow if the number of elements referenced by x exceeds a number dependent upon the amount of available stack space. For many JVMs, the limit is between 9,000 and 10,000 assuming a relatively empty stack at the point of query execution. We have applications which occasionally use lists several times this size.
The stack overflow occurs in org.hibernate.hql.ast.util.NodeTraverser which uses a recursive algorithm to walk a parse tree. Long "in" lists generate a subtree of depth about equal to the number of elements in the list. A sufficiently long list results in a stack overflow when NodeTraverser's internal method visitDepthFirst calls itself too many times.
The solution is to replace the recursive tree walking strategy with an iterative one that does not use up stack space. I am attaching the source for a replacement version of . NodeTraverser which implements the iterative tree walking method.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://opensource.atlassian.com/projects/hibernate/secure/Administrators....
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
14 years, 4 months
[Hibernate-JIRA] Created: (HHH-3850) org.jboss.cache.lock.TimeoutException: failure acquiring lock, lock=<unlocked> (activeReaders=0, activeWriter=null, waitingReaders=0, waitingWriters=0, waitingUpgrader=0)
by wu bin (JIRA)
org.jboss.cache.lock.TimeoutException: failure acquiring lock, lock=<unlocked> (activeReaders=0, activeWriter=null, waitingReaders=0, waitingWriters=0, waitingUpgrader=0)
--------------------------------------------------------------------------------------------------------------------------------------------------------------------------
Key: HHH-3850
URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-3850
Project: Hibernate Core
Issue Type: Bug
Components: caching (L2)
Affects Versions: 3.2.6
Environment: linux , oracle 9.2 jboss 4.2.3
Reporter: wu bin
we use hibernate and jboss tree cache in jboss 4.2.3 in lnux.
we only have 1 node in the cluster.
we met this exception:
19:00:58,515 ERROR [TxInterceptor] method invocation failed
org.jboss.cache.lock.TimeoutException: failure acquiring lock: fqn=/org/hibernate/cache/UpdateTimestampsCache/LOG_EVENT, caller=GlobalTransaction:<16.173.241.57:9242>:119, lock=<unlocked> (activeReaders=0, activeWriter=null, waitingReaders=0, waitingWriters=0, waitingUpgrader=0)
at org.jboss.cache.Node.acquire(Node.java:533)
at org.jboss.cache.interceptors.PessimisticLockInterceptor.acquireNodeLock(PessimisticLockInterceptor.java:410)
at org.jboss.cache.interceptors.PessimisticLockInterceptor.lock(PessimisticLockInterceptor.java:322)
at org.jboss.cache.interceptors.PessimisticLockInterceptor.invoke(PessimisticLockInterceptor.java:189)
at org.jboss.cache.interceptors.Interceptor.invoke(Interceptor.java:68)
at org.jboss.cache.interceptors.UnlockInterceptor.invoke(UnlockInterceptor.java:32)
at org.jboss.cache.interceptors.Interceptor.invoke(Interceptor.java:68)
at org.jboss.cache.interceptors.ReplicationInterceptor.invoke(ReplicationInterceptor.java:39)
at org.jboss.cache.interceptors.Interceptor.invoke(Interceptor.java:68)
at org.jboss.cache.interceptors.TxInterceptor.replayModifications(TxInterceptor.java:568)
at org.jboss.cache.interceptors.TxInterceptor.handlePessimisticPrepare(TxInterceptor.java:472)
at org.jboss.cache.interceptors.TxInterceptor.handleRemotePrepare(TxInterceptor.java:338)
at org.jboss.cache.interceptors.TxInterceptor.invoke(TxInterceptor.java:145)
at org.jboss.cache.interceptors.Interceptor.invoke(Interceptor.java:68)
at org.jboss.cache.interceptors.CacheMgmtInterceptor.invoke(CacheMgmtInterceptor.java:183)
at org.jboss.cache.TreeCache.invokeMethod(TreeCache.java:5919)
at org.jboss.cache.TreeCache._replicate(TreeCache.java:5196)
at sun.reflect.GeneratedMethodAccessor200.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:585)
at org.jgroups.blocks.MethodCall.invoke(MethodCall.java:330)
at org.jgroups.blocks.RpcDispatcher.handle(RpcDispatcher.java:281)
at org.jgroups.blocks.RequestCorrelator.handleRequest(RequestCorrelator.java:654)
at org.jgroups.blocks.RequestCorrelator.receiveMessage(RequestCorrelator.java:544)
at org.jgroups.blocks.RequestCorrelator.receive(RequestCorrelator.java:367)
at org.jgroups.blocks.MessageDispatcher$ProtocolAdapter.up(MessageDispatcher.java:777)
at org.jgroups.JChannel.up(JChannel.java:1091)
at org.jgroups.stack.ProtocolStack.up(ProtocolStack.java:382)
at org.jgroups.stack.ProtocolStack.receiveUpEvent(ProtocolStack.java:398)
at org.jgroups.stack.Protocol.passUp(Protocol.java:520)
at org.jgroups.protocols.pbcast.STATE_TRANSFER.up(STATE_TRANSFER.java:158)
at org.jgroups.stack.UpHandler.run(Protocol.java:60)
Caused by: org.jboss.cache.lock.TimeoutException: write lock for /org/hibernate/cache/UpdateTimestampsCache/LOG_EVENT could not be acquired after 0 ms. Locks: Read lock owners: []
Write lock owner: Thread[http-8443-14,5,jboss]
(caller=GlobalTransaction:<16.173.241.57:9242>:119, lock info: <unlocked> (activeReaders=0, activeWriter=null, waitingReaders=0, waitingWriters=0, waitingUpgrader=0))
at org.jboss.cache.lock.IdentityLock.acquireWriteLock(IdentityLock.java:206)
at org.jboss.cache.Node.acquireWriteLock(Node.java:562)
at org.jboss.cache.Node.acquire(Node.java:509)
... 31 more
19:00:58,516 ERROR [TxInterceptor] prepare method invocation failed
java.lang.RuntimeException: org.jboss.cache.lock.TimeoutException: failure acquiring lock: fqn=/org/hibernate/cache/UpdateTimestampsCache/LOG_EVENT, caller=GlobalTransaction:<16.173.241.57:9242>:119, lock=<unlocked> (activeReaders=0, activeWriter=null, waitingReaders=0, waitingWriters=0, waitingUpgrader=0)
at org.jboss.cache.interceptors.TxInterceptor.replayModifications(TxInterceptor.java:591)
at org.jboss.cache.interceptors.TxInterceptor.handlePessimisticPrepare(TxInterceptor.java:472)
at org.jboss.cache.interceptors.TxInterceptor.handleRemotePrepare(TxInterceptor.java:338)
at org.jboss.cache.interceptors.TxInterceptor.invoke(TxInterceptor.java:145)
at org.jboss.cache.interceptors.Interceptor.invoke(Interceptor.java:68)
at org.jboss.cache.interceptors.CacheMgmtInterceptor.invoke(CacheMgmtInterceptor.java:183)
at org.jboss.cache.TreeCache.invokeMethod(TreeCache.java:5919)
at org.jboss.cache.TreeCache._replicate(TreeCache.java:5196)
at sun.reflect.GeneratedMethodAccessor200.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:585)
at org.jgroups.blocks.MethodCall.invoke(MethodCall.java:330)
at org.jgroups.blocks.RpcDispatcher.handle(RpcDispatcher.java:281)
at org.jgroups.blocks.RequestCorrelator.handleRequest(RequestCorrelator.java:654)
at org.jgroups.blocks.RequestCorrelator.receiveMessage(RequestCorrelator.java:544)
at org.jgroups.blocks.RequestCorrelator.receive(RequestCorrelator.java:367)
at org.jgroups.blocks.MessageDispatcher$ProtocolAdapter.up(MessageDispatcher.java:777)
at org.jgroups.JChannel.up(JChannel.java:1091)
at org.jgroups.stack.ProtocolStack.up(ProtocolStack.java:382)
at org.jgroups.stack.ProtocolStack.receiveUpEvent(ProtocolStack.java:398)
at org.jgroups.stack.Protocol.passUp(Protocol.java:520)
at org.jgroups.protocols.pbcast.STATE_TRANSFER.up(STATE_TRANSFER.java:158)
at org.jgroups.stack.UpHandler.run(Protocol.java:60)
Caused by: org.jboss.cache.lock.TimeoutException: failure acquiring lock: fqn=/org/hibernate/cache/UpdateTimestampsCache/LOG_EVENT, caller=GlobalTransaction:<16.173.241.57:9242>:119, lock=<unlocked> (activeReaders=0, activeWriter=null, waitingReaders=0, waitingWriters=0, waitingUpgrader=0)
at org.jboss.cache.Node.acquire(Node.java:533)
at org.jboss.cache.interceptors.PessimisticLockInterceptor.acquireNodeLock(PessimisticLockInterceptor.java:410)
at org.jboss.cache.interceptors.PessimisticLockInterceptor.lock(PessimisticLockInterceptor.java:322)
at org.jboss.cache.interceptors.PessimisticLockInterceptor.invoke(PessimisticLockInterceptor.java:189)
at org.jboss.cache.interceptors.Interceptor.invoke(Interceptor.java:68)
at org.jboss.cache.interceptors.UnlockInterceptor.invoke(UnlockInterceptor.java:32)
at org.jboss.cache.interceptors.Interceptor.invoke(Interceptor.java:68)
at org.jboss.cache.interceptors.ReplicationInterceptor.invoke(ReplicationInterceptor.java:39)
at org.jboss.cache.interceptors.Interceptor.invoke(Interceptor.java:68)
at org.jboss.cache.interceptors.TxInterceptor.replayModifications(TxInterceptor.java:568)
... 22 more
Caused by: org.jboss.cache.lock.TimeoutException: write lock for /org/hibernate/cache/UpdateTimestampsCache/LOG_EVENT could not be acquired after 0 ms. Locks: Read lock owners: []
Write lock owner: Thread[http-8443-14,5,jboss]
(caller=GlobalTransaction:<16.173.241.57:9242>:119, lock info: <unlocked> (activeReaders=0, activeWriter=null, waitingReaders=0, waitingWriters=0, waitingUpgrader=0))
at org.jboss.cache.lock.IdentityLock.acquireWriteLock(IdentityLock.java:206)
at org.jboss.cache.Node.acquireWriteLock(Node.java:562)
at org.jboss.cache.Node.acquire(Node.java:509)
... 31 more
19:00:58,516 WARN [TreeCache] replication failure with method_call prepare; id:10; Args: ( arg[0] = GlobalTransaction:<16.173.241.57:9242>:119 ...) exception
java.lang.RuntimeException: org.jboss.cache.lock.TimeoutException: failure acquiring lock: fqn=/org/hibernate/cache/UpdateTimestampsCache/LOG_EVENT, caller=GlobalTransaction:<16.173.241.57:9242>:119, lock=<unlocked> (activeReaders=0, activeWriter=null, waitingReaders=0, waitingWriters=0, waitingUpgrader=0)
at org.jboss.cache.interceptors.TxInterceptor.replayModifications(TxInterceptor.java:591)
at org.jboss.cache.interceptors.TxInterceptor.handlePessimisticPrepare(TxInterceptor.java:472)
at org.jboss.cache.interceptors.TxInterceptor.handleRemotePrepare(TxInterceptor.java:338)
at org.jboss.cache.interceptors.TxInterceptor.invoke(TxInterceptor.java:145)
at org.jboss.cache.interceptors.Interceptor.invoke(Interceptor.java:68)
at org.jboss.cache.interceptors.CacheMgmtInterceptor.invoke(CacheMgmtInterceptor.java:183)
at org.jboss.cache.TreeCache.invokeMethod(TreeCache.java:5919)
at org.jboss.cache.TreeCache._replicate(TreeCache.java:5196)
at sun.reflect.GeneratedMethodAccessor200.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:585)
at org.jgroups.blocks.MethodCall.invoke(MethodCall.java:330)
at org.jgroups.blocks.RpcDispatcher.handle(RpcDispatcher.java:281)
at org.jgroups.blocks.RequestCorrelator.handleRequest(RequestCorrelator.java:654)
at org.jgroups.blocks.RequestCorrelator.receiveMessage(RequestCorrelator.java:544)
at org.jgroups.blocks.RequestCorrelator.receive(RequestCorrelator.java:367)
at org.jgroups.blocks.MessageDispatcher$ProtocolAdapter.up(MessageDispatcher.java:777)
at org.jgroups.JChannel.up(JChannel.java:1091)
at org.jgroups.stack.ProtocolStack.up(ProtocolStack.java:382)
at org.jgroups.stack.ProtocolStack.receiveUpEvent(ProtocolStack.java:398)
at org.jgroups.stack.Protocol.passUp(Protocol.java:520)
at org.jgroups.protocols.pbcast.STATE_TRANSFER.up(STATE_TRANSFER.java:158)
at org.jgroups.stack.UpHandler.run(Protocol.java:60)
Caused by: org.jboss.cache.lock.TimeoutException: failure acquiring lock: fqn=/org/hibernate/cache/UpdateTimestampsCache/LOG_EVENT, caller=GlobalTransaction:<16.173.241.57:9242>:119, lock=<unlocked> (activeReaders=0, activeWriter=null, waitingReaders=0, waitingWriters=0, waitingUpgrader=0)
at org.jboss.cache.Node.acquire(Node.java:533)
at org.jboss.cache.interceptors.PessimisticLockInterceptor.acquireNodeLock(PessimisticLockInterceptor.java:410)
at org.jboss.cache.interceptors.PessimisticLockInterceptor.lock(PessimisticLockInterceptor.java:322)
at org.jboss.cache.interceptors.PessimisticLockInterceptor.invoke(PessimisticLockInterceptor.java:189)
at org.jboss.cache.interceptors.Interceptor.invoke(Interceptor.java:68)
at org.jboss.cache.interceptors.UnlockInterceptor.invoke(UnlockInterceptor.java:32)
at org.jboss.cache.interceptors.Interceptor.invoke(Interceptor.java:68)
at org.jboss.cache.interceptors.ReplicationInterceptor.invoke(ReplicationInterceptor.java:39)
at org.jboss.cache.interceptors.Interceptor.invoke(Interceptor.java:68)
at org.jboss.cache.interceptors.TxInterceptor.replayModifications(TxInterceptor.java:568)
... 22 more
Caused by: org.jboss.cache.lock.TimeoutException: write lock for /org/hibernate/cache/UpdateTimestampsCache/LOG_EVENT could not be acquired after 0 ms. Locks: Read lock owners: []
Write lock owner: Thread[http-8443-14,5,jboss]
(caller=GlobalTransaction:<16.173.241.57:9242>:119, lock info: <unlocked> (activeReaders=0, activeWriter=null, waitingReaders=0, waitingWriters=0, waitingUpgrader=0))
at org.jboss.cache.lock.IdentityLock.acquireWriteLock(IdentityLock.java:206)
at org.jboss.cache.Node.acquireWriteLock(Node.java:562)
at org.jboss.cache.Node.acquire(Node.java:509)
... 31 more
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://opensource.atlassian.com/projects/hibernate/secure/Administrators....
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
14 years, 4 months