[Hibernate-JIRA] Created: (HHH-4839) database being down, the transaction patterns fail
by Dean Hiller (JIRA)
database being down, the transaction patterns fail
--------------------------------------------------
Key: HHH-4839
URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-4839
Project: Hibernate Core
Issue Type: Bug
Components: core
Affects Versions: 3.3.2
Environment: jboss5.1, seam2.2.0
Reporter: Dean Hiller
Priority: Critical
Many frameworks and hibernate even suggests to use the pattern that on every http request, start a transaction and at the end commit it even if no sql is going to be run. This works great if using the postgres jdbc driver in which the driver never talks to the db unless sql is done, BUT the postgres XA driver, oracle JDBC driver and oracle XA driver all fail this same test.....
1. create a static page that requires no sql to be run(no selects, updates nor inserts)
2. in seam go to the static page
3. transaction failure using one of the last 3 drivers above(again, postgres driver works fine).
In seam, it is even worse, users ended up in an infinite redirect when our database went down which then caused jboss to go down from all the traffic of infinite requests from all our users(IE only...firefox kicks users out of the infinite redirect). This pattern is great as long as hibernate puts a proxy adapter or something in front of all the datasources and jdbc drivers which will only open a connection if sql is actually going to be run(lazy open connection!!!!).
With the oracle driver, the call to commit results in talking to db even though no sql was run.
With postgres XA datasource and oracle XA datasource, they both try to open a connection when the transaction starts instead of lazily opening the connection when the first sql is run instead.
I tried the user forums here...
https://forum.hibernate.org/viewtopic.php?f=1&t=1002203
but got no responses. I filed a seam bug that I will tie to this bug to be tracked as well as I am not sure where this would get fixed. There is stack traces in the seam bug...
https://jira.jboss.org/jira/browse/JBSEAM-4528
thanks,
Dean
--
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
16 years, 2 months
[Hibernate-JIRA] Created: (HHH-4637) Check whether any custom entity/collection's cache usage is correct
by Galder Zamarreno (JIRA)
Check whether any custom entity/collection's cache usage is correct
-------------------------------------------------------------------
Key: HHH-4637
URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-4637
Project: Hibernate Core
Issue Type: New Feature
Reporter: Galder Zamarreno
Assignee: Galder Zamarreno
Fix For: 3.5
[quote from Brian]Next, re: collection caching: I noticed that my collection caches weren't being created by the InfinispanRegionFactory (and no exceptions were thrown when I set custom eviction settings for them), so I looked through SessionFactoryImpl in the Hibernate code and saw that I have to explicitly set <cache usage=transactional/> on each collection, even if the owning entity has the transactional cache usage set (otherwise SessionFactoryImpl will never call buildCollectionRegion and collection caching won't get turned on). Is this the intended behavior (that the cache usage has to be set explicitly on each collection)? If so it might be useful to throw an exception in the InfinispanRegionFactory if the cache usage isn't set up as above, since in my case I had custom eviction settings for a collection that referred to a cache region that didn't exist. [/quote]
Hmmm, I suppose InfinispanRegionFactory might be able to check for any custom settings for any entity/collection and do a check for it, i.e. check if cache usage is transactional or read-only. Any other time where there's no specific setting per entity/collection, I don't think we can do that.
http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4268562#4268562
--
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
16 years, 2 months
[Hibernate-JIRA] Created: (HHH-4693) MapProxy - problems during marshalling/demarchalling
by Lawrence McAlpin (JIRA)
MapProxy - problems during marshalling/demarchalling
----------------------------------------------------
Key: HHH-4693
URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-4693
Project: Hibernate Core
Issue Type: Bug
Components: envers
Affects Versions: 3.5.0-Beta-2
Environment: envers version: 1.2.1-hibernate-3.3, 3.5.0-Beta-2
hsqldb, sybase
Reporter: Lawrence McAlpin
Priority: Minor
Attachments: testsrc.zip, transient.patch
This is related to an issue resolved in HHH-4488.
When attempting to serialize an @audited entity that contains a Map, we get the following exception:
Caused by: java.io.NotSerializableException: org.hibernate.envers.entities.mapper.relation.lazy.initializor.MapCollectionInitializor
at java.io.ObjectOutputStream.writeObject0(ObjectOutputStream.java:1081)
at java.io.ObjectOutputStream.defaultWriteFields(ObjectOutputStream.java:1375)
at java.io.ObjectOutputStream.writeSerialData(ObjectOutputStream.java:1347)
at java.io.ObjectOutputStream.writeOrdinaryObject(ObjectOutputStream.java:1290)
at java.io.ObjectOutputStream.writeObject0(ObjectOutputStream.java:1079)
at java.io.ObjectOutputStream.defaultWriteFields(ObjectOutputStream.java:1375)
at java.io.ObjectOutputStream.writeSerialData(ObjectOutputStream.java:1347)
at java.io.ObjectOutputStream.writeOrdinaryObject(ObjectOutputStream.java:1290)
at java.io.ObjectOutputStream.writeObject0(ObjectOutputStream.java:1079)
at java.io.ObjectOutputStream.writeObject(ObjectOutputStream.java:302)
In the patch submitted with HHH-4488, the collection initializer for a CollectionProxy was made transient. However, MapProxy and SortedMapProxy do not extend from CollectionProxy and have their own collection initializer field. My patch simply marks it transient in those classes as well.
--
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
16 years, 2 months
[Hibernate-JIRA] Created: (HHH-4068) Hibernate's ReadWriteCache synchronization slow down ehcache
by shaoxian yang (JIRA)
Hibernate's ReadWriteCache synchronization slow down ehcache
-------------------------------------------------------------
Key: HHH-4068
URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-4068
Project: Hibernate Core
Issue Type: Bug
Reporter: shaoxian yang
Hi, I am setting up hibernate to work with ehcache. Hibernate has a wrapper to call underlying ehcache.
Their wrappers are ReadWriteCache.java, which internally will call Ehcache. The two major methods in ReadWriteCache are synchronized:
public synchronized Object get(Object key, long txTimestamp) throws CacheException {
public synchronized boolean put(
Object key,
Object value,
long txTimestamp,
Object version,
Comparator versionComparator,
boolean minimalPut)
I understand this is to ensure "read/write" strategy to read committed (when write and read thread get in at the same time, read does not get intermediate result and only get the latest committed result).
However, isn't this also make concurrent read impossible when there is no write? ).
It looks like we need some more advanced read/write lock at ReadWriteCache level. However, the class also have other synchronized methods which make me hesitate:
public synchronized SoftLock lock(Object key, Object version) throws CacheException
public synchronized void release(Object key, SoftLock clientLock) throws CacheException
public synchronized boolean afterUpdate(Object key, Object value, Object version, SoftLock clientLock)
throws CacheException
public synchronized boolean afterInsert(Object key, Object value, Object version)
throws CacheException
public synchronized SoftLock lock(Object key, Object version) throws CacheException
Basically I want to get the most out of ehcache performance gain. Currently, if I keep issuing the same query which read item from query cache, there is still overhead.
Can you advise me why we have to use read lock for every read when there is no write? And is it necessary to acquire lock for any other operation than put/get in ReadWriteCache class?
Thanks in advance.
--
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
16 years, 2 months
[Hibernate-JIRA] Created: (HHH-4817) Using hsqldb, import.sql fails w/ HsqlException: 'unexpected end of statement' if statements span lines.
by Chris Bedford (JIRA)
Using hsqldb, import.sql fails w/ HsqlException: 'unexpected end of statement' if statements span lines.
--------------------------------------------------------------------------------------------------------
Key: HHH-4817
URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-4817
Project: Hibernate Core
Issue Type: Bug
Environment: hsqldb - <artifactId>persistence-api</artifactId> <version>1.0</version> <artifactId>hibernate-entitymanager</artifactId> <version>3.2.1.ga</version>
Reporter: Chris Bedford
Priority: Minor
Attachments: jpa-spring-example.tar.gz
I have a very easily reproducible case that demonstrates this:
I have a schema initialization script that i keep in import.sql. When I run the script with the contents
of import.sql like this, SchemaExport finishes up with no complaint. (note all statements are on one line, with no newlines introduced for readability).
*** import.sql - each statement on one lines - no spanning lines ****
drop table UserLastNameHistory if exists;
create table UserLastNameHistory ( id INTEGER GENERATED BY DEFAULT AS IDENTITY, userid bigint not null, prevLastName varchar(255), newLastName varchar(255), primary key (id) ) ;
drop table User if exists;
create table User (id bigint not null, firstName varchar(255), lastName varchar(255), primary key (id)) ;
create trigger UserLastNameHistoryTrigger after update on User referencing new row as NEWER old row as OLDER FOR EACH ROW insert into UserLastNameHistory ( userid , prevLastName, newLastName) values (id, OLDER.lastName, NEWER.lastName) ;
*****end: import.sql *************************
Then when i introduce some newlines for readability I get the stack trace listed in Stack Trace, below.
SchemaExport fails to complete. Note when i run the exact statements (with newlines) in a sql
tool like squirrel it all runs fine.
*** import.sql - same content : newlines introduced for readability ****
drop table UserLastNameHistory if exists;
create table UserLastNameHistory (
id INTEGER GENERATED BY DEFAULT AS IDENTITY, userid bigint not null,
prevLastName varchar(255), newLastName varchar(255), primary key (id) ) ;
drop table User if exists;
create table User (id bigint not null, firstName varchar(255), lastName varchar(255), primary key (id)) ;
*****end: import.sql *************************
I have attached a very simple project that reproduces this issue.
to run it unzip it, go to top level directory and type
mvn test
Stack Trace
p1785 [main] ERROR org.hibernate.tool.hbm2ddl.SchemaExport - schema export unsuccessful
porg.hibernate.JDBCException: Error during import script execution
at org.hibernate.tool.hbm2ddl.SchemaExport.importScript(SchemaExport.java:258)
at org.hibernate.tool.hbm2ddl.SchemaExport.execute(SchemaExport.java:192)
at org.hibernate.tool.hbm2ddl.SchemaExport.create(SchemaExport.java:133)
at org.hibernate.impl.SessionFactoryImpl.<init>(SessionFactoryImpl.java:311)
at org.hibernate.cfg.Configuration.buildSessionFactory(Configuration.java:1291)
at org.hibernate.ejb.Ejb3Configuration.buildEntityManagerFactory(Ejb3Configuration.java:713)
at org.hibernate.ejb.HibernatePersistence.createContainerEntityManagerFactory(HibernatePersistence.java:127)
at org.springframework.orm.jpa.LocalContainerEntityManagerFactoryBean.createNativeEntityManagerFactory(LocalContainerEntityManagerFactoryBean.java:204)
at org.springframework.orm.jpa.AbstractEntityManagerFactoryBean.afterPropertiesSet(AbstractEntityManagerFactoryBean.java:242)
at org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.invokeInitMethods(AbstractAutowireCapableBeanFactory.java:1118)
at org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.initializeBean(AbstractAutowireCapableBeanFactory.java:1085)
at org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.createBean(AbstractAutowireCapableBeanFactory.java:429)
at org.springframework.beans.factory.support.AbstractBeanFactory$1.getObject(AbstractBeanFactory.java:250)
at org.springframework.beans.factory.support.DefaultSingletonBeanRegistry.getSingleton(DefaultSingletonBeanRegistry.java:141)
at org.springframework.beans.factory.support.AbstractBeanFactory.getBean(AbstractBeanFactory.java:247)
at org.springframework.beans.factory.support.AbstractBeanFactory.getBean(AbstractBeanFactory.java:161)
at org.springframework.beans.factory.support.DefaultListableBeanFactory.preInstantiateSingletons(DefaultListableBeanFactory.java:270)
at org.springframework.context.support.AbstractApplicationContext.refresh(AbstractApplicationContext.java:346)
at org.springframework.context.support.ClassPathXmlApplicationContext.<init>(ClassPathXmlApplicationContext.java:92)
at org.springframework.context.support.ClassPathXmlApplicationContext.<init>(ClassPathXmlApplicationContext.java:77)
at org.springframework.test.AbstractSingleSpringContextTests.loadContextLocations(AbstractSingleSpringContextTests.java:182)
at org.springframework.test.AbstractSingleSpringContextTests.loadContext(AbstractSingleSpringContextTests.java:152)
at org.springframework.test.AbstractSpringContextTests.getContext(AbstractSpringContextTests.java:105)
at org.springframework.test.AbstractSingleSpringContextTests.setUp(AbstractSingleSpringContextTests.java:83)
at junit.framework.TestCase.runBare(TestCase.java:125)
at org.springframework.test.ConditionalTestCase.runBare(ConditionalTestCase.java:69)
at junit.framework.TestResult$1.protect(TestResult.java:106)
at junit.framework.TestResult.runProtected(TestResult.java:124)
at junit.framework.TestResult.run(TestResult.java:109)
at junit.framework.TestCase.run(TestCase.java:118)
at junit.framework.TestSuite.runTest(TestSuite.java:208)
at junit.framework.TestSuite.run(TestSuite.java:203)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at org.apache.maven.surefire.junit.JUnitTestSet.execute(JUnitTestSet.java:213)
at org.apache.maven.surefire.suite.AbstractDirectoryTestSuite.executeTestSet(AbstractDirectoryTestSuite.java:140)
at org.apache.maven.surefire.suite.AbstractDirectoryTestSuite.execute(AbstractDirectoryTestSuite.java:127)
at org.apache.maven.surefire.Surefire.run(Surefire.java:177)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at org.apache.maven.surefire.booter.SurefireBooter.runSuitesInProcess(SurefireBooter.java:338)
at org.apache.maven.surefire.booter.SurefireBooter.main(SurefireBooter.java:997)
Caused by: java.sql.SQLException: Unexpected token: in statement [create table UserLastNameHistory (]
at org.hsqldb.jdbc.Util.sqlException(Unknown Source)
at org.hsqldb.jdbc.jdbcStatement.fetchResult(Unknown Source)
at org.hsqldb.jdbc.jdbcStatement.execute(Unknown Source)
at org.hibernate.tool.hbm2ddl.SchemaExport.importScript(SchemaExport.java:254)
... 45 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
16 years, 2 months