I am using H2 (embedded) with Hibernate 3.1
My server app is using HSQLDB and I am experimenting with H2 mainly
because it supports serialized transactions where HSQLDB only supports
Read uncommitted.
All my tables except 1 are readonly. With HSQLDB I have synchronized
access to my non-readonly to overcome this limitation. When using H2
I removed this synchronization. Under a very light load I now get
timeouts trying modify my non-readonly table.
Logging out and exceptions should below.
I set "SET LOCK_TIMEOUT 5000", but it does not seem to make a
difference.
My Hibernate config sets the following properties that may be
relavent.
hibernateConfiguration.setProperty("hibernate.current_session_context_class","thread");
hibernateConfiguration.setProperty("hibernate.transaction.factory_class","org.hibernate.transaction.JDBCTransactionFactory");
15:55:36,734 WARN JDBCExceptionReporter:71 - SQL Error: 50200,
SQLState: HYT00
15:55:36,734 ERROR JDBCExceptionReporter:72 - Timeout trying to lock
table ACCESSGRANTS [HYT00-55]
java.lang.RuntimeException: java.lang.RuntimeException:
org.hibernate.exception.GenericJDBCException: could not insert:
[AccessGrant]
15:57:49,062 WARN JDBCExceptionReporter:71 - SQL Error: 50200,
SQLState: HYT00
15:57:49,062 ERROR JDBCExceptionReporter:72 - Timeout trying to lock
table ACCESSGRANTS [HYT00-55]
15:57:49,062 ERROR AbstractFlushingEventListener:301 - Could not
synchronize database state with session
org.hibernate.exception.GenericJDBCException: could not update:
[ca.digitalrapids.licenseServer.constraints.model.AccessGrant#2]
at
org.hibernate.exception.SQLStateConverter.handledNonSpecificException(SQLStateConverter.java:
103)
at
org.hibernate.exception.SQLStateConverter.convert(SQLStateConverter.java:
91)
at
org.hibernate.exception.JDBCExceptionHelper.convert(JDBCExceptionHelper.java:
43)
at
org.hibernate.persister.entity.AbstractEntityPersister.update(AbstractEntityPersister.java:
2360)
at
org.hibernate.persister.entity.AbstractEntityPersister.updateOrInsert(AbstractEntityPersister.java:
2242)
at
org.hibernate.persister.entity.AbstractEntityPersister.update(AbstractEntityPersister.java:
2542)
at
org.hibernate.action.EntityUpdateAction.execute(EntityUpdateAction.java:
92)
at org.hibernate.engine.ActionQueue.execute(ActionQueue.java:
248)
at
org.hibernate.engine.ActionQueue.executeActions(ActionQueue.java:232)
at
org.hibernate.engine.ActionQueue.executeActions(ActionQueue.java:140)
at
org.hibernate.event.def.AbstractFlushingEventListener.performExecutions(AbstractFlushingEventListener.java:
298)
at
org.hibernate.event.def.DefaultFlushEventListener.onFlush(DefaultFlushEventListener.java:
27)
at org.hibernate.impl.SessionImpl.flush(SessionImpl.java:1000)
at
org.hibernate.impl.SessionImpl.managedFlush(SessionImpl.java:338)
at
org.hibernate.transaction.JDBCTransaction.commit(JDBCTransaction.java:
106)
Maybe some queries are slow, could you check the .trace.db file? If
only one table is updated/deleted/inserted, it can't be the 'dining
philosophers' problem (see
http://en.wikipedia.org/wiki/Dining_philosophers_problem). Could you
use the database URL of this form:
jdbc:h2:~/test;TRACE_LEVEL_FILE=3
and then send me or post the .trace.db file (compressed if possible)?
Thanks,
Thomas
It turns out this was an problem within the application that was not
noticed until I tried using H2.
Thanks for your quick reply to my initial post.
On Aug 29, 1:47 pm, "Thomas Mueller" <thomas.tom.muel...@gmail.com>
wrote:
> > Under a very light load I now get
> > timeouts trying modify my non-readonly table.
>
> Maybe some queries are slow, could you check the .trace.db file? If
> only one table is updated/deleted/inserted, it can't be the 'dining
> philosophers' problem (seehttp://en.wikipedia.org/wiki/Dining_philosophers_problem). Could you