[Hibernate-JIRA] Created: (HHH-3339) Query cache stops working after object save
by Alex Oleynikov (JIRA)
Query cache stops working after object save
-------------------------------------------
Key: HHH-3339
URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-3339
Project: Hibernate3
Issue Type: Bug
Components: caching (L2)
Affects Versions: 3.2.6
Environment: Hibernate 3.2.6, MS SQL 2005 Database. Windows XP SP2
Reporter: Alex Oleynikov
It seems like HB Query cache stops working as soon as given object type is being saved (it does not matter if it was save to existing object or insert of new object instance).
The code looks like this. Where User is just a primitive POJO with couple of properties.
// #1
query = session.createQuery("from User where userID = :id");
query.setCacheable(true);
query.setParameter("id", 10);
user = (User) query.list().get(0);
// #2
query = session.createQuery("from User where userID = :id");
query.setCacheable(true);
query.setParameter("id", 10);
user = (User) query.list().get(0);
// insert new User object
user = new User();
user.setUserID((int)(Math.random() * Integer.MAX_VALUE));
user.setUserName("Ten");
session.beginTransaction();
session.save(user);
session.getTransaction().commit();
// #3
query = session.createQuery("from User where userID = :id");
query.setCacheable(true);
query.setParameter("id", 10);
user = (User) query.list().get(0);
// #4
query = session.createQuery("from User where userID = :id");
query.setCacheable(true);
query.setParameter("id", 10);
user = (User) query.list().get(0);
>From MS SQL Profiler I can clearly see that no queries is executed for #2 (e.g. it hit the cache), but queries are executed for #3 and #4. From HB debug log I see following:
For #2 Query (cache is hit) - correct:
06:54:25,337 DEBUG StandardQueryCache:102 - checking cached query results in region: org.hibernate.cache.StandardQueryCache
06:54:25,337 DEBUG StandardQueryCache:156 - Checking query spaces for up-to-dateness: [USERS]
06:54:25,337 DEBUG StandardQueryCache:117 - returning cached query results
During User insert:
06:54:25,368 DEBUG UpdateTimestampsCache:65 - Invalidating space [USERS], timestamp: 4967466866147328
For #3 Query:
06:54:25,368 DEBUG StandardQueryCache:156 - Checking query spaces for up-to-dateness: [USERS]
06:54:25,368 DEBUG UpdateTimestampsCache:86 - [USERS] last update timestamp: 4967466866147328, result set timestamp: 4967466865061888
06:54:25,368 DEBUG StandardQueryCache:113 - cached query results were not up to date
For #4 Query (or any subsequent query for this matter):
06:54:25,368 DEBUG StandardQueryCache:156 - Checking query spaces for up-to-dateness: [USERS]
06:54:25,368 DEBUG UpdateTimestampsCache:86 - [USERS] last update timestamp: 4967466866147328, result set timestamp: 4967466865061888
06:54:25,368 DEBUG StandardQueryCache:113 - cached query results were not up to date
Please note the timestamp numbers for #4 query - even though I would expect query to be re-cached in #3, it still shows old timestamp. So I may think that when re-caching a query it does not update cache entry timestamp which is not up-to-date due to save().
--
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, 9 months
[Hibernate-JIRA] Created: (HHH-3407) @TableGenerator does not increment pkColumnValue by allocationSize
by Dan Ciarniello (JIRA)
@TableGenerator does not increment pkColumnValue by allocationSize
------------------------------------------------------------------
Key: HHH-3407
URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-3407
Project: Hibernate3
Issue Type: Bug
Affects Versions: 3.2.6, 3.2.4
Environment: JBoss 4.2.3, RHEL4, JDK1.5
Reporter: Dan Ciarniello
According to the JPA, the allocationSize attribute to @TableGenerator is "The amount to increment by when allocating id numbers from the generator" but the value is actually incremented by 1 regardless of allocationSize. The id is generated properly apparently according to the formula
id = lastkeyval*allocationSize + i where 0<i<allocationSize
The problems with this algorithm are:
1. One cannot tell what the next key value range is from the key table without knowing the allocationSize (minor)
2. If the allocationSize is reduced, already existing key values will be generated (major)
3. If two applications are configured with different allocation sizes, there will be an overlap in generated values (major)
--
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, 10 months
[Hibernate-JIRA] Created: (HHH-2131) SYBASE +select for update is showing deadlock because lock is not working properly
by George Thomas (JIRA)
SYBASE +select for update is showing deadlock because lock is not working properly
----------------------------------------------------------------------------------
Key: HHH-2131
URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-2131
Project: Hibernate3
Type: Bug
Components: core
Versions: 3.1.3
Environment: sybaseASE 12.5.03 in solaris +hibernate3.1.3
Reporter: George Thomas
I am connecting to Sybase database from hibernate.I tried setting locks using while selecting rows
1.session.load(class,id,LOCKMODE.UPGRADE)
2.session.lock(obj,LOCKMODE.UPGRADE)
I am attaching a sample code while updating a field in table fund after selecting it.
{
Fund fund = null;
ClientCredential credential = new ClientCredential("testDatabase", fund);
org.hibernate.Session session = SessionFactoryManager.getSessionFactory(credential).getCurrentSession();
Transaction transaction = session.beginTransaction();
log.info("Run by " + Thread.currentThread().getName());
fund = (Fund) session.get(Fund.class, new Short((short)12), LockMode.UPGRADE);
fund.setLegalEntityOrgId(fund.getLegalEntityOrgId()+1);
transaction.commit();
}
my requirement was that i wanted to do a select for update.I should acquire lock on certain rows and do a matching and if concurrent request comes ,it should wait till transaction is over that is lock is released.
When I went through the hibernate code,the hibernate is making static queries in the beginning while loading session factory.Since we are appending the holdlock during execution,the sybase dialect is not appending.
As a work around I tested with native sql with holdlock but when I test concurrent request using threads its bombing.Its throwing LockAcquisitionException.( Your server command (family id #0, process id #3777) encountered a deadlock situation.).can anyone give a solution to this problem???
org.hibernate.exception.LockAcquisitionException: could not update: [com.citco.aexeo.common.dataaccess.domain.Fund#12]
at org.hibernate.exception.SQLStateConverter.convert(SQLStateConverter.java:84)
at org.hibernate.exception.JDBCExceptionHelper.convert(JDBCExceptionHelper.java:43)
at org.hibernate.persister.entity.AbstractEntityPersister.update(AbstractEntityPersister.java:2223)
at org.hibernate.persister.entity.AbstractEntityPersister.updateOrInsert(AbstractEntityPersister.java:2118)
at org.hibernate.persister.entity.AbstractEntityPersister.update(AbstractEntityPersister.java:2375)
at org.hibernate.action.EntityUpdateAction.execute(EntityUpdateAction.java:91)
at org.hibernate.engine.ActionQueue.execute(ActionQueue.java:250)
at org.hibernate.engine.ActionQueue.executeActions(ActionQueue.java:233)
at org.hibernate.engine.ActionQueue.executeActions(ActionQueue.java:140)
at org.hibernate.event.def.AbstractFlushingEventListener.performExecutions(AbstractFlushingEventListener.java:297)
at org.hibernate.event.def.DefaultFlushEventListener.onFlush(DefaultFlushEventListener.java:27)
at org.hibernate.impl.SessionImpl.flush(SessionImpl.java:985)
at org.hibernate.impl.SessionImpl.managedFlush(SessionImpl.java:333)
at org.hibernate.transaction.JDBCTransaction.commit(JDBCTransaction.java:107)
at com.satyam.Testing.doTransaction(Testing.java:103)
at com.satyam.MyRunnable.run(MyRunnable.java:13)
at java.lang.Thread.run(Thread.java:568)
Caused by: com.sybase.jdbc2.jdbc.SybSQLException: Your server command (family id #0, process id #3777) encountered a deadlock situation. Please re-run your command.
at com.sybase.jdbc2.tds.Tds.processEed(Tds.java:2636)
at com.sybase.jdbc2.tds.Tds.nextResult(Tds.java:1996)
at com.sybase.jdbc2.jdbc.ResultGetter.nextResult(ResultGetter.java:69)
at com.sybase.jdbc2.jdbc.SybStatement.nextResult(SybStatement.java:204)
at com.sybase.jdbc2.jdbc.SybStatement.nextResult(SybStatement.java:187)
at com.sybase.jdbc2.jdbc.SybStatement.updateLoop(SybStatement.java:1642)
at com.sybase.jdbc2.jdbc.SybStatement.executeUpdate(SybStatement.java:1625)
at com.sybase.jdbc2.jdbc.SybPreparedStatement.executeUpdate(SybPreparedStatement.java:91)
at org.hibernate.jdbc.NonBatchingBatcher.addToBatch(NonBatchingBatcher.java:23)
at org.hibernate.persister.entity.AbstractEntityPersister.update(AbstractEntityPersister.java:2205)
... 14 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, 10 months
[Hibernate-JIRA] Created: (HHH-2691) Insert Into Select command outputs incorrect exception
by John Aylward (JIRA)
Insert Into Select command outputs incorrect exception
------------------------------------------------------
Key: HHH-2691
URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-2691
Project: Hibernate3
Issue Type: Bug
Components: query-hql
Affects Versions: 3.2.4.sp1
Environment: Hibernate 3.2.4.sp1 with Annotations 3.3.0 And Validator 3.0.0
MySQL 5.0.42
Reporter: John Aylward
receive following exception:
org.hibernate.QueryException: number of select types did not match those for insert [INSERT INTO ProviderInvoiceLineItem (amount,billingAccount,circuit,description,invoice,type) SELECT pili.amount,pili.billingAccount,pili.circuit,pili.description,:newInvoice,pili.type) FROM com.cicat.bedrock.billing.model.ProviderInvoiceLineItem pili WHERE pili.invoice = :oldInvoice]
exception should be that token ')' is not excepected near "pili.type"
Should not have gotten as far as it did, should have blown up on parsing the HQL
--
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, 10 months
[Hibernate-JIRA] Created: (HHH-2374) setFetchMode() ignore incorect path
by Baptiste MATHUS (JIRA)
setFetchMode() ignore incorect path
-----------------------------------
Key: HHH-2374
URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-2374
Project: Hibernate3
Type: Bug
Versions: 3.2.0.ga
Environment: All DB I guess
Reporter: Baptiste MATHUS
This bug report is in fact a copy of the one that was already present in H2 : http://opensource.atlassian.com/projects/hibernate/browse/HB-763 . It does not seem to have changed in H3.
When calling setFetchMode("path", FetchMode.JOIN) on a criteria, even if the path is not correct, Hibernate does not complain. Its behaviour seems to be to simply ignore this bad path. I guess this should throw an exception. In fact, the bad thing of ignoring bad path is that if the developer was wrong specifying the path (typo, for example), then the join simply won't happen :-/.
I wrote a very simple testcase :
public void testFindClients()
{
Session session = HibernateUtil.currentSession();
session.beginTransaction();
Client c = (Client)session.createCriteria(Client.class).setFetchMode("foo", FetchMode.JOIN)
.setFetchMode("foo.bar", FetchMode.JOIN).uniqueResult();
session.getTransaction().commit();
}
My Client class has some relationships with other classes, but obviously none named "foo". The code above just issue the following select :
select
this_.ID as ID0_0_,
this_.nom as nom0_0_,
this_.prenom as prenom0_0_,
this_.age as age0_0_
from
Client this_
Thanks again for your great work, guys!
--
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, 10 months
[Hibernate-JIRA] Created: (HHH-2344) Persistent collection queued operation ignored with lazy inverse one-to-many collection.
by Sebastien Robert (JIRA)
Persistent collection queued operation ignored with lazy inverse one-to-many collection.
----------------------------------------------------------------------------------------
Key: HHH-2344
URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-2344
Project: Hibernate3
Type: Bug
Components: core
Versions: 3.2.1
Environment: Hibernate 3.2.1
Reporter: Sebastien Robert
I load an Object that contains a lazy inverse collection (one-to-many).
Hibernate wrap my collection with a PersistentMap
There is objects in the collection in the database but in my case the PersistentMap is not yet initialized.
I perform a remove operation on the persistentMap with a known key of one of the objects.
The map is not initialized (and the relation is an inverse one-to-many) so the map queue the removeOperation.
I perform a get operation with the same key and the value is still returned.
If we look closer at what happened in the PersistentMap, it's look like this.
//*****
public Object remove(Object key) {
if ( isPutQueueEnabled() ) { // This returned true, the
// map is not yet
// initialized
Object old = readElementByIndex( key ); // This method triggered
// an initialization of the
// map.
// Queued operation are
// processed in the after
// init method
queueOperation( new Remove( key, old ) ); // The remove operation
// is queued.
return old;
}
....
//*******
When i perform the get operation on the map the map is now initialized. The get is processed by the underlying map and the value is returned. The queued operation is completely ignored.
Currently i fixed my code by performing a containsKey before the remove . The containsKey initialize the map and then the remove do not queue the operation. But by looking at all the PersistentCollection it seem that i may have the same problem using put and remove with other persistentCollection.
--
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, 10 months
[Hibernate-JIRA] Created: (HHH-2068) TransientObjectException : object references an unsaved transient instance ...
by Ales PROCHAZKA (JIRA)
TransientObjectException : object references an unsaved transient instance ...
------------------------------------------------------------------------------
Key: HHH-2068
URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-2068
Project: Hibernate3
Type: Bug
Components: core
Versions: 3.2.0.cr4
Environment: Windows, Hibernate 3.2.0.cr4, Oracle 9.2.0.1
Reporter: Ales PROCHAZKA
Attachments: XTest.zip
I found this problem:
If I create new object 'o1', which associate another persistent object 'o2' and by calling saveOrUpdate Hibernate throws PropertyValueException,
then when I corresct this property and try call saveOrUpdate in another session (in which 'o2' was not saved or loaded) Hibernate throws TransientObjectException.
Please see attached code :-)
This is a log :
Hibernate: select hibernate_sequence.nextval from dual
Hibernate: insert into T_TEST (A_POKUS, A_POKUS_LONG, CID, PK) values (?, ?, 3, ?)
Hibernate: insert into T_TEST3 (PK) values (?)
Hibernate: select hibernate_sequence.nextval from dual
Hibernate: select hibernate_sequence.nextval from dual
org.hibernate.PropertyValueException: not-null property references a null or transient value: persistent.Test5.pokus
at org.hibernate.engine.Nullability.checkNullability(Nullability.java:72)
at org.hibernate.event.def.AbstractSaveEventListener.performSaveOrReplicate(AbstractSaveEventListener.java:284)
at org.hibernate.event.def.AbstractSaveEventListener.performSave(AbstractSaveEventListener.java:180)
at org.hibernate.event.def.AbstractSaveEventListener.saveWithGeneratedId(AbstractSaveEventListener.java:121)
at org.hibernate.event.def.DefaultSaveOrUpdateEventListener.saveWithGeneratedOrRequestedId(DefaultSaveOrUpdateEventListener.java:186)
at org.hibernate.event.def.DefaultSaveOrUpdateEventListener.entityIsTransient(DefaultSaveOrUpdateEventListener.java:175)
at org.hibernate.event.def.DefaultSaveOrUpdateEventListener.performSaveOrUpdate(DefaultSaveOrUpdateEventListener.java:98)
at org.hibernate.event.def.DefaultSaveOrUpdateEventListener.onSaveOrUpdate(DefaultSaveOrUpdateEventListener.java:70)
at org.hibernate.impl.SessionImpl.fireSaveOrUpdate(SessionImpl.java:509)
at org.hibernate.impl.SessionImpl.saveOrUpdate(SessionImpl.java:501)
at org.hibernate.impl.SessionImpl.saveOrUpdate(SessionImpl.java:497)
at test.MainTest.test(MainTest.java:71)
at test.MainTest.main(MainTest.java:42)
org.hibernate.TransientObjectException: persistent.Test3
at org.hibernate.engine.ForeignKeys.getEntityIdentifierIfNotUnsaved(ForeignKeys.java:216)
at org.hibernate.type.EntityType.getIdentifier(EntityType.java:108)
at org.hibernate.type.ManyToOneType.isDirty(ManyToOneType.java:221)
at org.hibernate.type.TypeFactory.findDirty(TypeFactory.java:476)
at org.hibernate.persister.entity.AbstractEntityPersister.findDirty(AbstractEntityPersister.java:2900)
at org.hibernate.event.def.DefaultFlushEntityEventListener.dirtyCheck(DefaultFlushEntityEventListener.java:474)
at org.hibernate.event.def.DefaultFlushEntityEventListener.isUpdateNecessary(DefaultFlushEntityEventListener.java:197)
at org.hibernate.event.def.DefaultFlushEntityEventListener.onFlushEntity(DefaultFlushEntityEventListener.java:120)
at org.hibernate.event.def.AbstractFlushingEventListener.flushEntities(AbstractFlushingEventListener.java:195)
at org.hibernate.event.def.AbstractFlushingEventListener.flushEverythingToExecutions(AbstractFlushingEventListener.java:76)
at org.hibernate.event.def.DefaultFlushEventListener.onFlush(DefaultFlushEventListener.java:26)
at org.hibernate.impl.SessionImpl.flush(SessionImpl.java:993)
at org.hibernate.impl.SessionImpl.managedFlush(SessionImpl.java:340)
at org.hibernate.transaction.JDBCTransaction.commit(JDBCTransaction.java:106)
at test.MainTest.test(MainTest.java:87)
at test.MainTest.main(MainTest.java:42)
Thanx
--
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, 10 months
[Hibernate-JIRA] Created: (ANN-755) Cascade operations don't take affect through a @CollectionOfElements
by Chris L (JIRA)
Cascade operations don't take affect through a @CollectionOfElements
--------------------------------------------------------------------
Key: ANN-755
URL: http://opensource.atlassian.com/projects/hibernate/browse/ANN-755
Project: Hibernate Annotations
Issue Type: Bug
Affects Versions: 3.3.0.ga
Environment: Hibernate 3.2.5
Reporter: Chris L
Consider having three classes. The first is an @Entity called a View, which has a collection of @Embeddable Column objects. Column objects have an @ManyToOne relationship to a @Entity called Filter.
The three classes have a very straightforward mapping:
@javax.persistence.Entity()
@Entity(dynamicUpdate=true)
@Table(name="PORTFOLIO_VIEW")
class View {
....
@JoinTable(name="PORTFOLIO_VIEW_COLUMN",joinColumns={@JoinColumn(name="VIEW_ID")})
@IndexColumn(name="COLUMN_INDEX")
@Cascade(CascadeType.ALL)
@LazyCollection(LazyCollectionOption.FALSE)
@CollectionOfElements
private List<Column> columns;
....
}
@Embeddable
class Column {
....
@ManyToOne(fetch=FetchType.EAGER)
@Cascade(CascadeType.ALL)
@JoinColumn(name="FILTER")
@Target(FilterImpl.class)
private Filter filter;
....
}
@javax.persistence.Entity
@Entity(dynamicUpdate=true)
@Table(name="FILTER")
@DiscriminatorColumn(name="CLASS_NAME",length=255)
abstract class FilterImpl {
....
}
When I create a new view, with a new column and filter object, I should be able to save the view and have the @Cascade settings on the @CollectionOfElements and the @ManyToOne inside of Column take affect, and save the Filter. Instead, I get a TransientObjectException because the Filter hasn't been saved yet.
I know I could work around this by either making Column an Entity, or by adding code to save the Filter before saving the View. But it seems to me this is reasonable usage of an Embeddable.
This issue was originally part of a forum post http://forum.hibernate.org/viewtopic.php?t=987977
--
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, 10 months