[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
12 years, 7 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
12 years, 7 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
12 years, 7 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
12 years, 7 months
[Hibernate-JIRA] Created: (HHH-4577) 2L query cache: Low performance of flush and commit due many unnecessary (pre)invalidate calls on UpdateTimestampsCache
by Guenther Demetz (JIRA)
2L query cache: Low performance of flush and commit due many unnecessary (pre)invalidate calls on UpdateTimestampsCache
-----------------------------------------------------------------------------------------------------------------------
Key: HHH-4577
URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-4577
Project: Hibernate Core
Issue Type: Improvement
Components: caching (L2)
Affects Versions: 3.3.2
Environment: Hibernate 3.3.2GA with JBossCache3.2.1.GA as 2L-cache provider
SQLServer2008
Reporter: Guenther Demetz
Analyzing what our application is mainly doing during flush/commit,
we saw that very often the concerning thread is executing in jbosscache stuff (see 2 sample stacktraces below).
Analyzing the code we discovered that, if doing 1000 inserts for a determinate entity:
-on flush UpdateTimestampsCache.preinvalidate() is called 1000 times for the same space (=table)
-on commit UpdateTimestampsCache.invalidate() is called another 1000 times again for the same space (=table)
It would be much smarter to collect the interested spaces once per flush and once per commit and then execute the (pre)invalidate once per single space. In the case above it would reduce the calls to one single UpdateTimestampsCache.preinvalidate()call on flush and one single UpdateTimestampsCache.invalidate() on commit.
For the commit the enhancement could be following:
ActionQueue.java:
public void afterTransactionCompletion(boolean success) {
int size = executions.size();
final boolean invalidateQueryCache = session.getFactory().getSettings().isQueryCacheEnabled();
Set<Serializable> spaces = invalidateQueryCache ? new HashSet<Serializable>() : null;
try {
for ( int i = 0; i < size; i++ ) {
try {
Executable exec = ( Executable ) executions.get( i );
if ( invalidateQueryCache ) {
Serializable[] nspaces = exec.getPropertySpaces();
for (int j=0; j < nspaces.length; j++)
spaces.add(nspaces[j]);
}
exec.afterTransactionCompletion( success );
}
catch ( CacheException ce ) {
log.error( "could not release a cache lock", ce );
// continue loop
}
catch ( Exception e ) {
throw new AssertionFailure( "Exception releasing cache locks", e );
}
}
}
finally {
session.getFactory().getUpdateTimestampsCache().invalidate(spaces.toArray(new Serializable[]{}));
}
executions.clear();
}
Stack traces:
java.lang.Thread.isInterrupted(Native Method)
java.lang.Thread.interrupted(Thread.java:873)
java.util.concurrent.locks.AbstractQueuedSynchronizer.acquireInterruptibly(AbstractQueuedSynchronizer.java:1134)
java.util.concurrent.locks.ReentrantLock.lockInterruptibly(ReentrantLock.java:312)
java.util.concurrent.LinkedBlockingQueue.put(LinkedBlockingQueue.java:241)
org.jboss.cache.RegionImpl.registerEvictionEvent(RegionImpl.java:249)
org.jboss.cache.RegionImpl.registerEvictionEvent(RegionImpl.java:234)
org.jboss.cache.interceptors.EvictionInterceptor.registerEvictionEventToRegionManager(EvictionInterceptor.java:252)
org.jboss.cache.interceptors.EvictionInterceptor.visitPutKeyValueCommand(EvictionInterceptor.java:109)
org.jboss.cache.commands.write.PutKeyValueCommand.acceptVisitor(PutKeyValueCommand.java:100)
org.jboss.cache.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:116)
org.jboss.cache.interceptors.MVCCLockingInterceptor.handlePutKeyValueCommand(MVCCLockingInterceptor.java:102)
org.jboss.cache.interceptors.base.PrePostProcessingCommandInterceptor.visitPutKeyValueCommand(PrePostProcessingCommandInterceptor.java:88)
org.jboss.cache.commands.write.PutKeyValueCommand.acceptVisitor(PutKeyValueCommand.java:100)
org.jboss.cache.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:116)
org.jboss.cache.interceptors.base.CommandInterceptor.handleDefault(CommandInterceptor.java:131)
org.jboss.cache.commands.AbstractVisitor.visitPutKeyValueCommand(AbstractVisitor.java:65)
org.jboss.cache.commands.write.PutKeyValueCommand.acceptVisitor(PutKeyValueCommand.java:100)
org.jboss.cache.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:116)
org.jboss.cache.interceptors.TxInterceptor.attachGtxAndPassUpChain(TxInterceptor.java:301)
org.jboss.cache.interceptors.TxInterceptor.handleDefault(TxInterceptor.java:283)
org.jboss.cache.commands.AbstractVisitor.visitPutKeyValueCommand(AbstractVisitor.java:65)
org.jboss.cache.commands.write.PutKeyValueCommand.acceptVisitor(PutKeyValueCommand.java:100)
org.jboss.cache.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:116)
org.jboss.cache.interceptors.CacheMgmtInterceptor.visitPutKeyValueCommand(CacheMgmtInterceptor.java:119)
org.jboss.cache.commands.write.PutKeyValueCommand.acceptVisitor(PutKeyValueCommand.java:100)
org.jboss.cache.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:116)
org.jboss.cache.interceptors.InvocationContextInterceptor.handleAll(InvocationContextInterceptor.java:178)
org.jboss.cache.interceptors.InvocationContextInterceptor.visitPutKeyValueCommand(InvocationContextInterceptor.java:82)
org.jboss.cache.commands.write.PutKeyValueCommand.acceptVisitor(PutKeyValueCommand.java:100)
org.jboss.cache.interceptors.InterceptorChain.invoke(InterceptorChain.java:287)
org.jboss.cache.invocation.CacheInvocationDelegate.put(CacheInvocationDelegate.java:555)
org.hibernate.cache.jbc2.util.CacheHelper.put(CacheHelper.java:212)
org.hibernate.cache.jbc2.timestamp.TimestampsRegionImpl.put(TimestampsRegionImpl.java:128)
org.hibernate.cache.UpdateTimestampsCache.preinvalidate(UpdateTimestampsCache.java:70)
- locked org.hibernate.cache.UpdateTimestampsCache@1afcaae
org.hibernate.engine.ActionQueue.execute(ActionQueue.java:275)
org.hibernate.engine.ActionQueue.executeActions(ActionQueue.java:263)
org.hibernate.engine.ActionQueue.executeActions(ActionQueue.java:167)
org.hibernate.event.def.AbstractFlushingEventListener.performExecutions(AbstractFlushingEventListener.java:321)
Stack trace:
java.lang.Thread.isInterrupted(Native Method)
java.lang.Thread.interrupted(Thread.java:873)
java.util.concurrent.locks.AbstractQueuedSynchronizer.tryAcquireNanos(AbstractQueuedSynchronizer.java:1158)
java.util.concurrent.locks.ReentrantLock.tryLock(ReentrantLock.java:416)
org.jboss.cache.util.concurrent.locks.AbstractSharedLockContainer.acquireLock(AbstractSharedLockContainer.java:94)
org.jboss.cache.lock.MVCCLockManager.lockAndRecord(MVCCLockManager.java:133)
org.jboss.cache.mvcc.MVCCNodeHelper.acquireLock(MVCCNodeHelper.java:157)
org.jboss.cache.mvcc.MVCCNodeHelper.wrapNodeForWriting(MVCCNodeHelper.java:217)
org.jboss.cache.mvcc.MVCCNodeHelper.wrapNodeForWriting(MVCCNodeHelper.java:186)
org.jboss.cache.interceptors.MVCCLockingInterceptor.handlePutKeyValueCommand(MVCCLockingInterceptor.java:101)
org.jboss.cache.interceptors.base.PrePostProcessingCommandInterceptor.visitPutKeyValueCommand(PrePostProcessingCommandInterceptor.java:88)
org.jboss.cache.commands.write.PutKeyValueCommand.acceptVisitor(PutKeyValueCommand.java:100)
org.jboss.cache.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:116)
org.jboss.cache.interceptors.base.CommandInterceptor.handleDefault(CommandInterceptor.java:131)
org.jboss.cache.commands.AbstractVisitor.visitPutKeyValueCommand(AbstractVisitor.java:65)
org.jboss.cache.commands.write.PutKeyValueCommand.acceptVisitor(PutKeyValueCommand.java:100)
org.jboss.cache.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:116)
org.jboss.cache.interceptors.TxInterceptor.attachGtxAndPassUpChain(TxInterceptor.java:301)
org.jboss.cache.interceptors.TxInterceptor.handleDefault(TxInterceptor.java:283)
org.jboss.cache.commands.AbstractVisitor.visitPutKeyValueCommand(AbstractVisitor.java:65)
org.jboss.cache.commands.write.PutKeyValueCommand.acceptVisitor(PutKeyValueCommand.java:100)
org.jboss.cache.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:116)
org.jboss.cache.interceptors.CacheMgmtInterceptor.visitPutKeyValueCommand(CacheMgmtInterceptor.java:119)
org.jboss.cache.commands.write.PutKeyValueCommand.acceptVisitor(PutKeyValueCommand.java:100)
org.jboss.cache.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:116)
org.jboss.cache.interceptors.InvocationContextInterceptor.handleAll(InvocationContextInterceptor.java:178)
org.jboss.cache.interceptors.InvocationContextInterceptor.visitPutKeyValueCommand(InvocationContextInterceptor.java:82)
org.jboss.cache.commands.write.PutKeyValueCommand.acceptVisitor(PutKeyValueCommand.java:100)
org.jboss.cache.interceptors.InterceptorChain.invoke(InterceptorChain.java:287)
org.jboss.cache.invocation.CacheInvocationDelegate.put(CacheInvocationDelegate.java:555)
org.hibernate.cache.jbc2.util.CacheHelper.put(CacheHelper.java:212)
org.hibernate.cache.jbc2.timestamp.TimestampsRegionImpl.put(TimestampsRegionImpl.java:128)
org.hibernate.cache.UpdateTimestampsCache.invalidate(UpdateTimestampsCache.java:85)
- locked org.hibernate.cache.UpdateTimestampsCache@1afcaae
org.hibernate.engine.ActionQueue.afterTransactionCompletion(ActionQueue.java:202)
--
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
12 years, 7 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
12 years, 7 months
[Hibernate-JIRA] Created: (HHH-2305) refresh throws exception when database has been altered with a delete
by Markus Heiden (JIRA)
refresh throws exception when database has been altered with a delete
---------------------------------------------------------------------
Key: HHH-2305
URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-2305
Project: Hibernate3
Type: Bug
Components: core
Versions: 3.2.1
Environment: Hibernate 3.2.1, Oracle 9.2
Reporter: Markus Heiden
Attachments: hibernate.zip
First I save an entity with a collection of cascading entities in it and flush. Then I delete these cascaded entities with a sql query. When I now do a refresh on the entity an exception is thrown, because the cascaded entities couldn't be found in the database. I expected these entities to be deleted from the (in memory) collection of the entity instead.
Test case is attached. Stacktrace of test case:
Hibernate: select c0_.id as id2_0_, c0_.c as c2_0_ from C c0_ where c0_.id=?
org.hibernate.UnresolvableObjectException: No row with the given identifier exists: [hibernate.refresh.C#30003]
at org.hibernate.UnresolvableObjectException.throwIfNull(UnresolvableObjectException.java:42)
at org.hibernate.event.def.DefaultRefreshEventListener.onRefresh(DefaultRefreshEventListener.java:126)
at org.hibernate.impl.SessionImpl.fireRefresh(SessionImpl.java:911)
at org.hibernate.impl.SessionImpl.refresh(SessionImpl.java:894)
at org.hibernate.engine.CascadingAction$4.cascade(CascadingAction.java:169)
at org.hibernate.engine.Cascade.cascadeToOne(Cascade.java:268)
at org.hibernate.engine.Cascade.cascadeAssociation(Cascade.java:216)
at org.hibernate.engine.Cascade.cascadeProperty(Cascade.java:169)
at org.hibernate.engine.Cascade.cascadeCollectionElements(Cascade.java:296)
at org.hibernate.engine.Cascade.cascadeCollection(Cascade.java:242)
at org.hibernate.engine.Cascade.cascadeAssociation(Cascade.java:219)
at org.hibernate.engine.Cascade.cascadeProperty(Cascade.java:169)
at org.hibernate.engine.Cascade.cascade(Cascade.java:130)
at org.hibernate.event.def.DefaultRefreshEventListener.onRefresh(DefaultRefreshEventListener.java:99)
at org.hibernate.impl.SessionImpl.fireRefresh(SessionImpl.java:911)
at org.hibernate.impl.SessionImpl.refresh(SessionImpl.java:894)
at org.hibernate.engine.CascadingAction$4.cascade(CascadingAction.java:169)
at org.hibernate.engine.Cascade.cascadeToOne(Cascade.java:268)
at org.hibernate.engine.Cascade.cascadeAssociation(Cascade.java:216)
at org.hibernate.engine.Cascade.cascadeProperty(Cascade.java:169)
at org.hibernate.engine.Cascade.cascadeCollectionElements(Cascade.java:296)
at org.hibernate.engine.Cascade.cascadeCollection(Cascade.java:242)
at org.hibernate.engine.Cascade.cascadeAssociation(Cascade.java:219)
at org.hibernate.engine.Cascade.cascadeProperty(Cascade.java:169)
at org.hibernate.engine.Cascade.cascade(Cascade.java:130)
at org.hibernate.event.def.DefaultRefreshEventListener.onRefresh(DefaultRefreshEventListener.java:99)
at org.hibernate.event.def.DefaultRefreshEventListener.onRefresh(DefaultRefreshEventListener.java:39)
at org.hibernate.impl.SessionImpl.fireRefresh(SessionImpl.java:902)
at org.hibernate.impl.SessionImpl.refresh(SessionImpl.java:886)
at hibernate.refresh.Test.main(Test.java:46)
--
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
12 years, 7 months
[Hibernate-JIRA] Created: (HHH-3360) Custom Oracle Batcher to allow batch updates for versioned data
by Manuel Dominguez Sarmiento (JIRA)
Custom Oracle Batcher to allow batch updates for versioned data
---------------------------------------------------------------
Key: HHH-3360
URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-3360
Project: Hibernate3
Issue Type: Improvement
Components: core
Affects Versions: 3.3.0.CR1, 3.2.6, 3.2.5, 3.2.4.sp1, 3.2.4, 3.2.3, 3.2.2, 3.2.1, 3.2.0.ga
Environment: Oracle 10g R1, 10g R2, 11g R1 (have not tried previous Oracle versions), 11g R1 drivers (older drivers should also work)
Reporter: Manuel Dominguez Sarmiento
Priority: Minor
Attachments: C3P0OracleBatchingBatcher.java, C3P0OracleBatchingBatcherFactory.java, OracleBatchingBatcher.java, OracleBatchingBatcherFactory.java
We have developed a custom Oracle Batcher which allows batching versioned data. The Oracle JDBC driver does not return update counts when using the standard JDBC 2.0 batching mechanism, however the proprietary Oracle batching mechanism allows obtaining the total batch row update count. The update counts are absolutely necessary to detect stale updates.
Although it is not exactly the same, the total row update count is actually enough information to be able to batch versioned data and still detect stale updates.
We'd like to contribute the attached files. They have a compile time dependency on Oracle JDBC. If this is not acceptable, it could be easily solved by using reflection.
Another Batcher is provided for when the Oracle connection is being managed through c3p0 (a common deployment scenario). This has a compile time dependency on c3p0.
A few "dirty" tricks were necessary to pull this off without patching other classes. Specifically, it was necessary to override Java private semantics to obtain BasicExpectation.expectedRowCount. This could be easily solved by adding an accessor method to the Expectation interface.
There is one issue which we are not completely sure of, however so far we have not found any problems. When the Expectation is NONE, there is no way to check whether the total row count is correct or not, even if other batched updates do have expectations with expected row counts. Our understanding is that actually, since batching requires all statements to be of the same type (since the same PreparedStatement / CallableStatement is being used), then either ALL expectations will be NONE, or all will have an expected row count. We'd welcome comments from the Hibernate team. This could also be probably handled better by improving the Expectation interface.
Oracle JDBC docs that explain the Oracle batching model: http://download.oracle.com/docs/cd/B28359_01/java.111/b31224/oraperf.htm#...
As expected, implementing this solution has resulted in drastical improvement in batch processing.
--
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
12 years, 7 months