[Hibernate-JIRA] Resolved: (HHH-1764) Cache invalidation in OptimisticTreeCache conflicts with JTA transactions
by Strong Liu (JIRA)
[ http://opensource.atlassian.com/projects/hibernate/browse/HHH-1764?page=c... ]
Strong Liu resolved HHH-1764.
-----------------------------
Resolution: Out of Date
> Cache invalidation in OptimisticTreeCache conflicts with JTA transactions
> -------------------------------------------------------------------------
>
> Key: HHH-1764
> URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-1764
> Project: Hibernate Core
> Issue Type: Patch
> Components: core
> Affects Versions: 3.2.0.cr2
> Environment: Hibernate 3.1.3 with added OptimisticTreeCache classes from 3.2.0.cr2, JBoss Cache 1.3 SP2, JBoss 4.0.3 SP1, PostgreSQL 8.1.2
> Reporter: Jaka Jaksic
> Attachments: OptimisticTreeCache.patch
>
> Original Estimate: 10m
> Remaining Estimate: 10m
>
> After switching to Hibernate 3.2.0.cr2's OptimisticTreeCache, exceptions started to occur after every commit. The reason is that, unlike TreeCache, OptimisticTreeCache doesn't perform cache invalidation _outside_ the scope of JTA transaction, even though the comment in its put() method states so... So because cache invalidation happens after commit, when the tx status is set to 3 (STATUS_COMMITTED), which TreeCache finds invalid, the following exception occurs:
> 00:53:51,754 WARN [TreeCache] status is 3 (not ACTIVE or PREPARING); returning null)
> 00:53:51,754 INFO [TxInterceptor] There was a problem handling this request org.jboss.cache.CacheException: Must be in a valid transaction _put(null, /org/hibernate/cache/UpdateTimestampsCache/EVENT_LOG, item, 11479064317, true)
> The original TreeCache properly bypasses JTA transaction by calling suspend(). I don't know why OptimisticTreeCache doesn't do that as well. I just copied that code from the TreeCache class and it seems to work well.
> If there is a reason why OptimisticTreeCache should not do it this way, please let me know what it is and how to solve this problem properly. Otherwise just use the provided patch.
> Here's the full stack trace:
> 00:53:51,754 WARN [TreeCache] status is 3 (not ACTIVE or PREPARING); returning null)
> 00:53:51,754 INFO [TxInterceptor] There was a problem handling this request org.jboss.cache.CacheException: Must be in a valid transaction _put(null, /org/hibernate/cache/UpdateTimestampsCache/EVENT_LOG, item, 11479064317, true)
> at org.jboss.cache.interceptors.OptimisticNodeInterceptor.invoke(OptimisticNodeInterceptor.java:113)
> at org.jboss.cache.interceptors.Interceptor.invoke(Interceptor.java:67)
> at org.jboss.cache.interceptors.OptimisticCreateIfNotExistsInterceptor.invoke(OptimisticCreateIfNotExistsInterceptor.java:68)
> at org.jboss.cache.interceptors.Interceptor.invoke(Interceptor.java:67)
> at org.jboss.cache.interceptors.OptimisticValidatorInterceptor.invoke(OptimisticValidatorInterceptor.java:76)
> at org.jboss.cache.interceptors.Interceptor.invoke(Interceptor.java:67)
> at org.jboss.cache.interceptors.OptimisticLockingInterceptor.invoke(OptimisticLockingInterceptor.java:116)
> at org.jboss.cache.interceptors.Interceptor.invoke(Interceptor.java:67)
> at org.jboss.cache.interceptors.TxInterceptor.handleNonTxMethod(TxInterceptor.java:328)
> at org.jboss.cache.interceptors.TxInterceptor.invoke(TxInterceptor.java:139)
> at org.jboss.cache.interceptors.Interceptor.invoke(Interceptor.java:67)
> at org.jboss.cache.interceptors.CacheMgmtInterceptor.invoke(CacheMgmtInterceptor.java:153)
> at org.jboss.cache.TreeCache.invokeMethod(TreeCache.java:4804)
> at org.jboss.cache.TreeCache.put(TreeCache.java:3242)
> at org.jboss.cache.TreeCache.put(TreeCache.java:2937)
> at org.hibernate.cache.OptimisticTreeCache.put(OptimisticTreeCache.java:139)
> at org.hibernate.cache.UpdateTimestampsCache.invalidate(UpdateTimestampsCache.java:67)
> at org.hibernate.engine.ActionQueue.afterTransactionCompletion(ActionQueue.java:174)
> at org.hibernate.impl.SessionImpl.afterTransactionCompletion(SessionImpl.java:419)
> at org.hibernate.jdbc.JDBCContext.afterTransactionCompletion(JDBCContext.java:209)
> at org.hibernate.transaction.CacheSynchronization.afterCompletion(CacheSynchronization.java:85)
> at org.jboss.tm.TransactionImpl.doAfterCompletion(TransactionImpl.java:1508)
> at org.jboss.tm.TransactionImpl.completeTransaction(TransactionImpl.java:1180)
> at org.jboss.tm.TransactionImpl.commit(TransactionImpl.java:359)
> at org.jboss.tm.TxManager.commit(TxManager.java:224)
> at org.jboss.tm.usertx.client.ServerVMClientUserTransaction.commit(ServerVMClientUserTransaction.java:126)
> at org.hibernate.transaction.JTATransaction.commit(JTATransaction.java:146)
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
13 years, 2 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
13 years, 2 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
13 years, 2 months
[Hibernate-JIRA] Created: (HSEARCH-977) MassIndexer freezes when there is an indexed 'id' filed, which is not document's id
by Igor (JIRA)
MassIndexer freezes when there is an indexed 'id' filed, which is not document's id
-----------------------------------------------------------------------------------
Key: HSEARCH-977
URL: http://opensource.atlassian.com/projects/hibernate/browse/HSEARCH-977
Project: Hibernate Search
Issue Type: Bug
Components: massindexer
Affects Versions: 3.4.0.Final
Environment: Mac, Linux, MySQL 5.1.x; Java 1.6, Hibernate 3.6.3.Final, hibernate-jpa-2.0-api 1.0.0.Final (entity annotations), Spring 3.0.5.RELEASE
Reporter: Igor
MassIndexer hangs (and the reason was quite difficult to figure out from logs...) when I have the following
(I simplified the actual class/interface hierarchy in this example; this should not matter I believe...):
// PK sits in a super class
@Entity
@Inheritance(strategy = InheritanceType.SINGLE_TABLE)
@DiscriminatorColumn(length=40)
@org.hibernate.annotations.Entity(dynamicUpdate = true, dynamicInsert = true)
public abstract class MyElementImpl implements MyElement {
// ...
@Id
@DocumentId
public String getRDFId()
{
return uri;
}
//etc...
}
// in an entity sub-class I have a property/column 'id' -
@Entity
@org.hibernate.annotations.Entity(dynamicUpdate = true, dynamicInsert = true)
public class XrefImpl extends MyElementImpl implements Xref
{
//...
@Field(name="id", index=Index.TOKENIZED)
@Column(name="id")
public String getId()
{
return refId;
}
public void setId(String id)
{
this.refId = id;
}
// etc...
This seems to be Hibernate Search framework issue. This may be also an issue for other Hibernate Search versions, but I do not remember which I have tried (I haven't tried the latest yet).
- though I found a workaround/fix that works for me (using another setter/getter and index field name):
// in the sub-class -
@Field(name="xrefId", index=Index.TOKENIZED)
@Column(name="id")
public String getIdx()
{
return refId;
}
public void setIdx(String id)
{
this.refId = id;
}
// make the actual interface method implementation transient
@Transient
public String getId()
...
Thank you.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
13 years, 2 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
13 years, 2 months
[Hibernate-JIRA] Updated: (HHH-1400) Using formula-based property causes invalid SQL code for children "subselect" query
by Rostyslav Smirnov (JIRA)
[ http://opensource.atlassian.com/projects/hibernate/browse/HHH-1400?page=c... ]
Rostyslav Smirnov updated HHH-1400:
-----------------------------------
Attachment: SubselectFetch.java.patch
Attached a patch with proposed fix that handles arbitrary nested queries.
> Using formula-based property causes invalid SQL code for children "subselect" query
> -----------------------------------------------------------------------------------
>
> Key: HHH-1400
> URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-1400
> Project: Hibernate Core
> Issue Type: Bug
> Components: core
> Affects Versions: 3.1 rc3
> Environment: Hibernate 3.0.5, Hibernate 3.1rc3
> Oracle 8i
> Reporter: Chris Rogers
> Attachments: SubselectFetch.java, SubselectFetch.java.patch, SubselectFormulaBug.zip, subselectformula.zip
>
>
> I have simple one-to-many relationship, mapped as set:
> <class name="Parent">
> <set name="children" lazy="false" fetch="subselect">
> <key column="PARENT_OID"/>
> <one-to-many class="Child"/>
> </set>
> </class>
> this works fine, constructing subselect SQL which looks like (e.g. for HQL query "from Parent"):
> select <child fields> from <child table> where child.PARENT_OID in (select this_.OID from PARENT this_)
> (simplified)
> However, when adding a formula-based property into Parent:
> <property name="myFormulaField" formula="(complex_select )"/>
> Now SQL becomes:
> select <child fields> from <child table> where PARENT_OID in (complex_select) as formula0_1_, <some parent fields> from PARENT this_)
> This SQL fails because of incorrect grammar (it also seems that backet is missing).
> This is something weird, because subselect fetching only needs Parent's identity column, not any other properties. And I don't think it should be affected by Parent's formula-based properties.
> I can provide more details if necessary, I stripped out all extra mapping/SQL stuff because it seems to be irrelevant here.
> This bug appeared in 3.0.5 later I've downloaded 3.1rc3 and it also fails.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
13 years, 2 months