[Hibernate-JIRA] Commented: (HHH-1100) Invalidate cache on StaleObjectStateException
by Nico De Groote (JIRA)
[ http://opensource.atlassian.com/projects/hibernate/browse/HHH-1100?page=c... ]
Nico De Groote commented on HHH-1100:
-------------------------------------
I did fix the problem mentioned above.
I performed the following change in the execute method of the EntityUpdateAction class.
...
if ( !veto ) {
try{
persister.update( id, fields, dirtyFields, hasDirtyCollection, oldFields, lastVersion, instance, rowId, session );
} catch (StaleObjectStateException ex){
if (persister.hasCache()){
EvictEvent evictEvent = new EvictEvent(instance, session);
session.getListeners().getEvictEventListener().onEvict(evictEvent);
}
throw ex;
}
}
...
It does the trick for me, however this might not be completely correct for you.
> Invalidate cache on StaleObjectStateException
> ----------------------------------------------
>
> Key: HHH-1100
> URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-1100
> Project: Hibernate3
> Type: Improvement
> Components: core
> Reporter: Gavin King
> Assignee: Gavin King
> Priority: Critical
>
>
> We should probably invalidate the second-level cache when a StaleObjectStateException occurs. Need to think this through.
--
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
19 years, 6 months
[Hibernate-JIRA] Resolved: (HHH-1529) session.merge(obj) with an uneffected 1:1 relationship throws an exception
by Emmanuel Bernard (JIRA)
[ http://opensource.atlassian.com/projects/hibernate/browse/HHH-1529?page=all ]
Emmanuel Bernard resolved HHH-1529:
-----------------------------------
Resolution: Duplicate
HHH-2138
> session.merge(obj) with an uneffected 1:1 relationship throws an exception
> --------------------------------------------------------------------------
>
> Key: HHH-1529
> URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-1529
> Project: Hibernate3
> Type: Bug
> Components: core
> Versions: 3.1.2
> Environment: Windows XP, Hibernate 3.1.2, JDK 5.0_06, PostgreSQL 8.1.2 (Oracle 10g XE beta3 as alternative)
> Reporter: Juergen Zimmermann
> Attachments: use-case-merge.zip
>
>
> Session.merge() crashes with util.JDBCExceptionReporter both on Oracle 10g XE and PostgreSQL 8.1.2. There is no problem when using the Session API and the according update() method. The use case is basically as follows (sources and 3rd party JARs are attached):
> Session session = sf.openSession();
> Transaction trans = session.getTransaction();
> CustomerEntity customer = session.find(CustomerEntity.class, 1L);
> trans.commit();
> session.close();
> customer.setName("Newvalue");
> session = sf.openSession();
> trans = session.getTransaction();
> session.merge(customer); // <== crash
> trans.commit();
> session.close();
> The "customer" object has a 1:1 relationship to an object of class SalesRepEntity. In the log file there is util.JDBCExceptionReporter. The problem is gone if I invoke session.refresh(customer.getSalesRep()) before invoking session.merge(customer). Also the problem is gone if I invoke session.update(customer) instead of session.merge(customer).
> Now the two stack traces (on a German Windows operating system).
> Stacktrace Oracle 10g XE:
>
> org.hibernate.exception.GenericJDBCException: could not load an entity: [de.crm.SalesRepEntity#id=1, name=Alpha]
> at org.hibernate.exception.SQLStateConverter.handledNonSpecificException(SQLStateConverter.java:91)
> at org.hibernate.exception.SQLStateConverter.convert(SQLStateConverter.java:79)
> at org.hibernate.exception.JDBCExceptionHelper.convert(JDBCExceptionHelper.java:43)
> at org.hibernate.loader.Loader.loadEntity(Loader.java:1799)
> at org.hibernate.loader.entity.AbstractEntityLoader.load(AbstractEntityLoader.java:93)
> at org.hibernate.loader.entity.EntityLoader.loadByUniqueKey(EntityLoader.java:85)
> at org.hibernate.persister.entity.AbstractEntityPersister.loadByUniqueKey(AbstractEntityPersister.java:1522)
> at org.hibernate.type.EntityType.loadByUniqueKey(EntityType.java:365)
> at org.hibernate.type.EntityType.resolve(EntityType.java:306)
> at org.hibernate.type.EntityType.replace(EntityType.java:207)
> at org.hibernate.type.TypeFactory.replace(TypeFactory.java:431)
> at org.hibernate.event.def.DefaultMergeEventListener.copyValues(DefaultMergeEventListener.java:281)
> at org.hibernate.event.def.DefaultMergeEventListener.entityIsDetached(DefaultMergeEventListener.java:247)
> at org.hibernate.event.def.DefaultMergeEventListener.onMerge(DefaultMergeEventListener.java:100)
> at org.hibernate.event.def.DefaultMergeEventListener.onMerge(DefaultMergeEventListener.java:52)
> at org.hibernate.impl.SessionImpl.fireMerge(SessionImpl.java:701)
> at org.hibernate.impl.SessionImpl.merge(SessionImpl.java:685)
> at org.hibernate.impl.SessionImpl.merge(SessionImpl.java:689)
> at de.crm.Crm.updateCustomer(Crm.java:72)
> at de.crm.Crm.main(Crm.java:32)
> Caused by: java.sql.SQLException: Fehlender IN- oder OUT-Parameter auf Index:: 1
> at oracle.jdbc.driver.DatabaseError.throwSqlException(DatabaseError.java:112)
> at oracle.jdbc.driver.DatabaseError.throwSqlException(DatabaseError.java:146)
> at oracle.jdbc.driver.OraclePreparedStatement.processCompletedBindRow(OraclePreparedStatement.java:1681)
> at oracle.jdbc.driver.OraclePreparedStatement.executeInternal(OraclePreparedStatement.java:3280)
> at oracle.jdbc.driver.OraclePreparedStatement.executeQuery(OraclePreparedStatement.java:3329)
> at org.hibernate.jdbc.AbstractBatcher.getResultSet(AbstractBatcher.java:139)
> at org.hibernate.loader.Loader.getResultSet(Loader.java:1669)
> at org.hibernate.loader.Loader.doQuery(Loader.java:662)
> at org.hibernate.loader.Loader.doQueryAndInitializeNonLazyCollections(Loader.java:224)
> at org.hibernate.loader.Loader.loadEntity(Loader.java:1785)
> ... 16 more
>
> Stacktrace PostgreSQL 8.1.2:
> org.hibernate.exception.DataException: could not load an entity: [de.crm.SalesRepEntity#id=1, name=Alpha]
> at org.hibernate.exception.SQLStateConverter.convert(SQLStateConverter.java:75)
> at org.hibernate.exception.JDBCExceptionHelper.convert(JDBCExceptionHelper.java:43)
> at org.hibernate.loader.Loader.loadEntity(Loader.java:1799)
> at org.hibernate.loader.entity.AbstractEntityLoader.load(AbstractEntityLoader.java:93)
> at org.hibernate.loader.entity.EntityLoader.loadByUniqueKey(EntityLoader.java:85)
> at org.hibernate.persister.entity.AbstractEntityPersister.loadByUniqueKey(AbstractEntityPersister.java:1522)
> at org.hibernate.type.EntityType.loadByUniqueKey(EntityType.java:365)
> at org.hibernate.type.EntityType.resolve(EntityType.java:306)
> at org.hibernate.type.EntityType.replace(EntityType.java:207)
> at org.hibernate.type.TypeFactory.replace(TypeFactory.java:431)
> at org.hibernate.event.def.DefaultMergeEventListener.copyValues(DefaultMergeEventListener.java:281)
> at org.hibernate.event.def.DefaultMergeEventListener.entityIsDetached(DefaultMergeEventListener.java:247)
> at org.hibernate.event.def.DefaultMergeEventListener.onMerge(DefaultMergeEventListener.java:100)
> at org.hibernate.event.def.DefaultMergeEventListener.onMerge(DefaultMergeEventListener.java:52)
> at org.hibernate.impl.SessionImpl.fireMerge(SessionImpl.java:701)
> at org.hibernate.impl.SessionImpl.merge(SessionImpl.java:685)
> at org.hibernate.impl.SessionImpl.merge(SessionImpl.java:689)
> at de.crm.Crm.updateCustomer(Crm.java:72)
> at de.crm.Crm.main(Crm.java:32)
> Caused by: org.postgresql.util.PSQLException: Für den Parameter 1 wurde kein Wert angegeben.
> at org.postgresql.core.v3.SimpleParameterList.checkAllParametersSet(SimpleParameterList.java:134)
> at org.postgresql.core.v3.QueryExecutorImpl.execute(QueryExecutorImpl.java:179)
> at org.postgresql.jdbc2.AbstractJdbc2Statement.execute(AbstractJdbc2Statement.java:437)
> at org.postgresql.jdbc2.AbstractJdbc2Statement.executeWithFlags(AbstractJdbc2Statement.java:353)
> at org.postgresql.jdbc2.AbstractJdbc2Statement.executeQuery(AbstractJdbc2Statement.java:257)
> at org.hibernate.jdbc.AbstractBatcher.getResultSet(AbstractBatcher.java:139)
> at org.hibernate.loader.Loader.getResultSet(Loader.java:1669)
> at org.hibernate.loader.Loader.doQuery(Loader.java:662)
> at org.hibernate.loader.Loader.doQueryAndInitializeNonLazyCollections(Loader.java:224)
> at org.hibernate.loader.Loader.loadEntity(Loader.java:1785)
--
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
19 years, 6 months
[Hibernate-JIRA] Commented: (HHH-1568) <subselect> returns stale data, <synchronize> doesn't evict <subselect> objects from session when session is flushed
by Max Rydahl Andersen (JIRA)
[ http://opensource.atlassian.com/projects/hibernate/browse/HHH-1568?page=c... ]
Max Rydahl Andersen commented on HHH-1568:
------------------------------------------
subselect is a *readonly* view on some data that you can't get to otherwise and would like to have them as entities.
nothing else; nothing more.
If you go and map two classes to the same table do you expect that changing the first will evict the second ?
in any case, such questions is for forum.hibernate.org not the jira.
> <subselect> returns stale data, <synchronize> doesn't evict <subselect> objects from session when session is flushed
> --------------------------------------------------------------------------------------------------------------------
>
> Key: HHH-1568
> URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-1568
> Project: Hibernate3
> Type: Bug
> Components: core
> Versions: 3.1.2
> Environment: Oracle 10g, Java 5, Windows,
> Reporter: Greg Matthews
> Attachments: SubselectTest.java, subselect_stale_data.log
>
>
> Stale data is being returned from a select against a Hibernate class based on a <subselect> element (instead of a table).
> See detailed log info attached.
> A flush is occuring againt entities referenced within <synchronize> elements in the <subclass> based class, but a subsequent HQL query executed against the <subclass> based class still returns stale data. The log details show that the <subclass> object is retrieved from session.
> Our expectation is that it makes sense for Hibernate to automatically evict objects from session when synchronization causes other entities to be flushed -- otherwise, the whole <synchronization> mechanism is useless and you might as well do everything manually via various evict calls.
> e.g.
> If I have 2 mapping files, one for Table A, and another for a <subselect> based on Table A (let's call this View_A, then I will declare a <synchonized> element in View_A so that any changes to A are flushed before records from View_A are retrieved.
> This seems to work ok in that A is flushed when a query against View_A being executed, but subsequent retrieval of View_A gets loaded from Session, and not from the DB like we'd expect.
> If we manually evict the rows from View_A before executing the HQL query against View_A then up-to-date data is retrieved from View_A.
> Another strange thing is that if we *query* View_A after editing records from A, then the following message appears....
> 12:43:24 DEBUG org.hibernate.engine.ActionQueue.areTablesToUpdated - changes must be flushed to space: A
> ...but if we *load* a record from View_A then this message above does not appear. I would have thought any attempt to access View_A after updates to A had occurred would trigger a flush to A. Hopefully the flush occurs behind the scenes in all cases, and it's just a case of a missing log message in the case of doing a session.load().
--
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
19 years, 6 months
[Hibernate-JIRA] Commented: (HB-892) NamingStrategy functionality
by Geoffrey De Smet (JIRA)
[ http://opensource.atlassian.com/projects/hibernate/browse/HB-892?page=com... ]
Geoffrey De Smet commented on HB-892:
-------------------------------------
Is there a similar issue for hibernate3 for this?
I'd like to get rid of the hashhash FK constraints.
> NamingStrategy functionality
> ----------------------------
>
> Key: HB-892
> URL: http://opensource.atlassian.com/projects/hibernate/browse/HB-892
> Project: Hibernate2
> Type: Improvement
> Reporter: Prasad Rachakonda
>
>
> In Hibernate version 2.1.1, We have something called "NamingStrategy" concept, which allows us to specify "Naming Standards" for database objects. We can provide rules for automatically generating database identifiers from Java dentifiers or for processing "logical" columns and table names given in the mapping file into "physical" table and column names.
> Note: This version of Hibernate only supports "tablenames" and "column names".
> It will be helpful if hibernate team can provide the "Naming Strategy support for other database objects,like.Foreign key constraint etc."
> Currently we are planning to use some temp solutions once we get the fix(probably in future releases), we will be using this feature.
> I appreciate your quick response.
--
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
19 years, 6 months
[Hibernate-JIRA] Commented: (HHH-1568) <subselect> returns stale data, <synchronize> doesn't evict <subselect> objects from session when session is flushed
by Greg Matthews (JIRA)
[ http://opensource.atlassian.com/projects/hibernate/browse/HHH-1568?page=c... ]
Greg Matthews commented on HHH-1568:
------------------------------------
Hi Max,
Thanks for the response and for your work on Hibernate. Great product.
I'm just trying to clarify the applicability of <subselect>
I'd appreciate it you can clarify at least one use of <subselect>. I can't see how this feature is useful at all in a real world application if you need to manually evict it to be sure its up to date. Is this what people do?
Thanks,
> <subselect> returns stale data, <synchronize> doesn't evict <subselect> objects from session when session is flushed
> --------------------------------------------------------------------------------------------------------------------
>
> Key: HHH-1568
> URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-1568
> Project: Hibernate3
> Type: Bug
> Components: core
> Versions: 3.1.2
> Environment: Oracle 10g, Java 5, Windows,
> Reporter: Greg Matthews
> Attachments: SubselectTest.java, subselect_stale_data.log
>
>
> Stale data is being returned from a select against a Hibernate class based on a <subselect> element (instead of a table).
> See detailed log info attached.
> A flush is occuring againt entities referenced within <synchronize> elements in the <subclass> based class, but a subsequent HQL query executed against the <subclass> based class still returns stale data. The log details show that the <subclass> object is retrieved from session.
> Our expectation is that it makes sense for Hibernate to automatically evict objects from session when synchronization causes other entities to be flushed -- otherwise, the whole <synchronization> mechanism is useless and you might as well do everything manually via various evict calls.
> e.g.
> If I have 2 mapping files, one for Table A, and another for a <subselect> based on Table A (let's call this View_A, then I will declare a <synchonized> element in View_A so that any changes to A are flushed before records from View_A are retrieved.
> This seems to work ok in that A is flushed when a query against View_A being executed, but subsequent retrieval of View_A gets loaded from Session, and not from the DB like we'd expect.
> If we manually evict the rows from View_A before executing the HQL query against View_A then up-to-date data is retrieved from View_A.
> Another strange thing is that if we *query* View_A after editing records from A, then the following message appears....
> 12:43:24 DEBUG org.hibernate.engine.ActionQueue.areTablesToUpdated - changes must be flushed to space: A
> ...but if we *load* a record from View_A then this message above does not appear. I would have thought any attempt to access View_A after updates to A had occurred would trigger a flush to A. Hopefully the flush occurs behind the scenes in all cases, and it's just a case of a missing log message in the case of doing a session.load().
--
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
19 years, 6 months