Thread: Postgres JDBC-hibernate Problem

Postgres JDBC-hibernate Problem

From
"Freddie Burgess"
Date:
We have upgraded from PostgreSQL 8.4.3 to PostgreSQL 9.1.4 and we are
getting the following errors when attempting to auto-gen schema DDL.

Old Configuration:

WEB-INF/lib/postgis-jdbc-1.3.3.jar,
WEB-INF/lib/postgis-stubs-1.3.3.jar,
WEB-INF/lib/postgresql-8.3-603.jdbc4.jar,

New Configuration:

Tomcat 7
Java 1.6.0_35

Spring Framework 3.1.2, hibernate sessionFactory via
'org.springframework.orm.hibernate4.LocalSessionFactoryBean'
Hibernate Core 4.1.6.Final
Hibernate Spatial 4.0.M1
PostgreSQL JDBC4 9.1-901
postgis-jdbc 1.5.2
c3p0 0.9.1.2

auto DDL update phase fails with Exception:

11:59:23,736 [localhost-startStop-1]  INFO java.sql.DatabaseMetaData:120 -
HHH000262: Table not found: SOME_TABLE
11:59:23,738 [localhost-startStop-1] ERROR
org.hibernate.tool.hbm2ddl.SchemaUpdate:245 - HHH000299: Could not complete
schema update

org.hibernate.MappingException: No Dialect mapping for JDBC type: 1852802018
(**Changes at each webapp startup)
        at org.hibernate.dialect.TypeNames.get(TypeNames.java:76)
        at org.hibernate.dialect.TypeNames.get(TypeNames.java:99)
        at org.hibernate.dialect.Dialect.getTypeName(Dialect.java:299)
        at
org.hibernate.spatial.dialect.postgis.PostgisDialect.getTypeName(PostgisDial
ect.java:247)
        at org.hibernate.mapping.Column.getSqlType(Column.java:227)
        at org.hibernate.mapping.Table.sqlCreateString(Table.java:481)
        at
org.hibernate.cfg.Configuration.generateSchemaUpdateScript(Configuration.jav
a:1140)
        at
org.hibernate.tool.hbm2ddl.SchemaUpdate.execute(SchemaUpdate.java:212)
        at
org.hibernate.tool.hbm2ddl.SchemaUpdate.execute(SchemaUpdate.java:178)
        at
org.hibernate.internal.SessionFactoryImpl.<init>(SessionFactoryImpl.java:492
)
        at
org.hibernate.cfg.Configuration.buildSessionFactory(Configuration.java:1746)
        at
org.hibernate.cfg.Configuration.buildSessionFactory(Configuration.java:1784)
        at
org.springframework.orm.hibernate4.LocalSessionFactoryBuilder.buildSessionFa
ctory(LocalSessionFactoryBuilder.java:242)
        at
org.springframework.orm.hibernate4.LocalSessionFactoryBean.buildSessionFacto
ry(LocalSessionFactoryBean.java:372)
        at
org.springframework.orm.hibernate4.LocalSessionFactoryBean.afterPropertiesSe
t(LocalSessionFactoryBean.java:357)
        at
org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory
.invokeInitMethods(AbstractAutowireCapableBeanFactory.java:1514)
        at
org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory
.initializeBean(AbstractAutowireCapableBeanFactory.java:1452)
        at
org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory
.doCreateBean(AbstractAutowireCapableBeanFactory.java:519)
        at
org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory
.createBean(AbstractAutowireCapableBeanFactory.java:456)
        at
org.springframework.beans.factory.support.AbstractBeanFactory$1.getObject(Ab
stractBeanFactory.java:294)
        at
org.springframework.beans.factory.support.DefaultSingletonBeanRegistry.getSi
ngleton(DefaultSingletonBeanRegistry.java:225)
        at
org.springframework.beans.factory.support.AbstractBeanFactory.doGetBean(Abst
ractBeanFactory.java:291)
        at
org.springframework.beans.factory.support.AbstractBeanFactory.getBean(Abstra
ctBeanFactory.java:193)
        at
org.springframework.beans.factory.support.BeanDefinitionValueResolver.resolv
eReference(BeanDefinitionValueResolver.java:322)
        at
org.springframework.beans.factory.support.BeanDefinitionValueResolver.resolv
eValueIfNecessary(BeanDefinitionValueResolver.java:106)
        at
org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory
.applyPropertyValues(AbstractAutowireCapableBeanFactory.java:1360)
        at
org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory
.populateBean(AbstractAutowireCapableBeanFactory.java:1118)
        at
org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory
.doCreateBean(AbstractAutowireCapableBeanFactory.java:517)
        at
org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory
.createBean(AbstractAutowireCapableBeanFactory.java:456)
        at
org.springframework.beans.factory.support.AbstractBeanFactory$1.getObject(Ab
stractBeanFactory.java:294)
        at
org.springframework.beans.factory.support.DefaultSingletonBeanRegistry.getSi
ngleton(DefaultSingletonBeanRegistry.java:225)
        at
org.springframework.beans.factory.support.AbstractBeanFactory.doGetBean(Abst
ractBeanFactory.java:291)
        at
org.springframework.beans.factory.support.AbstractBeanFactory.getBean(Abstra
ctBeanFactory.java:193)
        at
org.springframework.beans.factory.support.DefaultListableBeanFactory.preInst
antiateSingletons(DefaultListableBeanFactory.java:609)
        at
org.springframework.context.support.AbstractApplicationContext.finishBeanFac
toryInitialization(AbstractApplicationContext.java:918)
        at
org.springframework.context.support.AbstractApplicationContext.refresh(Abstr
actApplicationContext.java:469)
        at
org.springframework.web.context.ContextLoader.configureAndRefreshWebApplicat
ionContext(ContextLoader.java:383)
        at
org.springframework.web.context.ContextLoader.initWebApplicationContext(Cont
extLoader.java:283)
        at
org.springframework.web.context.ContextLoaderListener.contextInitialized(Con
textLoaderListener.java:111)
        at
org.apache.catalina.core.StandardContext.listenerStart(StandardContext.java:
4791)
        at
org.apache.catalina.core.StandardContext.startInternal(StandardContext.java:
5285)
        at
org.apache.catalina.util.LifecycleBase.start(LifecycleBase.java:150)
        at
org.apache.catalina.core.ContainerBase.addChildInternal(ContainerBase.java:9
01)
        at
org.apache.catalina.core.ContainerBase.addChild(ContainerBase.java:877)
        at
org.apache.catalina.core.StandardHost.addChild(StandardHost.java:618)
        at
org.apache.catalina.startup.HostConfig.deployWAR(HostConfig.java:963)
        at
org.apache.catalina.startup.HostConfig$DeployWar.run(HostConfig.java:1600)
        at
java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:441)
        at
java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303)
        at java.util.concurrent.FutureTask.run(FutureTask.java:138)
        at
java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.ja
va:886)
        at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:9
08)
        at java.lang.Thread.run(Thread.java:662)

Dialect specification in hibernate.properties is:
hibernate.dialect=org.hibernate.spatial.dialect.postgis.PostgisDialect

Any assistance will be greatly appreciated.

thanks
--

Re: Postgres JDBC-hibernate Problem

From
Craig Ringer
Date:
On 09/12/2012 12:18 AM, Freddie Burgess wrote:
> We have upgraded from PostgreSQL 8.4.3 to PostgreSQL 9.1.4 and we are
> getting the following errors when attempting to auto-gen schema DDL.

You've changed quite a bit at once, so it's a bit hard to narrow down.

Does the error occur when you run with the new PgJDBC and PostGIS
libraries against the *old* database server?

What about if you run with the old libraries against the new database
server? This might not work for other reasons, but is worth trying. If
it works, that suggests a regression in PgJDBC or PostGIS's client library.

--
Craig Ringer

Re: Postgres JDBC-hibernate Problem

From
"Freddie Burgess"
Date:
Thanks Craig,

We were able to make the necessary adjustments to the way Hibernate manages
the data types differently in version 4.1.6, so we got pass this error. Now
we have to tackle the a problem with the hibernate 4.1.6 batcher process no
longer allowing us to ingest data into the database. We are getting the
"nested transactions not supported error", even though the java developers
are telling me that they have only a single commit at the end of  their
logical transaction.

Caused by: org.hibernate.TransactionException: nested transactions not
supported
        at
org.hibernate.engine.transaction.spi.AbstractTransactionImpl.begin(AbstractT
ransactionImpl.java:152)
        at
org.hibernate.internal.SessionImpl.beginTransaction(SessionImpl.java:1396)
        at
im.app.empl.service.ingest.EmployeeWriter.handleEmployeeSegment(EmployeeWrit
er.java:309)
        at
im.app.empl.service.ingest.EmployeeWriter$3.onEvent(EmployeeWriter.java:116)
        at
im.app.empl.service.ingest.EmployeeWriter$3.onEvent(EmployeeWriter.java:113)
        at
org.bushe.swing.event.ThreadSafeEventService.publish(ThreadSafeEventService.
java:971)
        ... 5 more



-----Original Message-----
From: pgsql-bugs-owner@postgresql.org
[mailto:pgsql-bugs-owner@postgresql.org] On Behalf Of Craig Ringer
Sent: Monday, September 17, 2012 12:39 AM
To: Freddie Burgess
Cc: pgsql-bugs@postgresql.org
Subject: Re: [BUGS] Postgres JDBC-hibernate Problem

On 09/12/2012 12:18 AM, Freddie Burgess wrote:
> We have upgraded from PostgreSQL 8.4.3 to PostgreSQL 9.1.4 and we are
> getting the following errors when attempting to auto-gen schema DDL.

You've changed quite a bit at once, so it's a bit hard to narrow down.

Does the error occur when you run with the new PgJDBC and PostGIS libraries
against the *old* database server?

What about if you run with the old libraries against the new database
server? This might not work for other reasons, but is worth trying. If it
works, that suggests a regression in PgJDBC or PostGIS's client library.

--
Craig Ringer


--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes
to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs

Re: Postgres JDBC-hibernate Problem

From
Craig Ringer
Date:
On 09/18/2012 01:23 AM, Freddie Burgess wrote:
> Thanks Craig,
>
> We were able to make the necessary adjustments to the way Hibernate manages
> the data types differently in version 4.1.6, so we got pass this error. Now
> we have to tackle the a problem with the hibernate 4.1.6 batcher process no
> longer allowing us to ingest data into the database. We are getting the
> "nested transactions not supported error", even though the java developers
> are telling me that they have only a single commit at the end of  their
> logical transaction.

Look at the PostgreSQL logs and see. It's easier to trace if you set
log_line_prefix to something like:

log_line_prefix = '<a=%a,u=%u,db=%d,pid=%p,vtx=%v,tx=%x,cmd=%i>'

which produces significantly more verbose logs but makes it easier to,
using the pid and txix/vtxid info, work out how different logged
statements fit into transactions.

--
Craig Ringer

Re: Postgres JDBC-hibernate Problem

From
"Freddie Burgess"
Date:
Here is a more detailed write-up of our current problem.

We have a process that feeds three Postgresql database tables, two of which
are partitioned tables. There are no foreign key constraint dependencies
between any of these tables.

Data get parsed and subsequently ingested into these tables in no particular
order, but the process fails to load a single row!

Background

Previously, when we had hibernate 3.22 GA running. it was necessary for us
to add the following hibernate configuration parameter to address inserts
into the two partitioned tables on 3.22 GA:

# Enable when using Postgres with partitioned tables
#hibernate.jdbc.factory_class=im.empl.core.service.ingest.postgres.PostgresP
artitionBatcherFactory
...
...
...

Problem

This setting is no longer configurable in Hibernate 4.1.2

Table(s) included in the logical transaction Summary

Table name   Structure
----------   ---------------
Employee     non-partitioned
stockoptions partitioned
trading      partitioned

While attempting to upgrade Hibernate to release 4.1.2, we started to
receive the "nested transactions not supported" exception error

11:21:10,897 [Thread-7250]  INFO
im.empl.core.service.ingest.OptionsWriter:171 - Received stockoptions
segment before any Employee segment.
11:21:10,897 [Thread-7250]  INFO
im.empl.core.service.ingest.TradingWriter:297 - Received trading segment
before any Employee segment.
11:21:10,897 [Thread-7250]  INFO
im.empl.core.service.ingest.TradingWriter:297 - Received trading segment
before any Employee segment.
11:21:10,897 [Thread-7250]  INFO
im.empl.core.service.ingest.TradingWriter:297 - Received trading segment
before any Employee segment.
11:21:10,897 [Thread-53]  WARN org.bushe.swing.event.EventService:? -
Exception thrown by;EventService
subscriber:im.empl.core.service.ingest.EmployeeWriter$3@4dd25f53.
Subscriber class:class im.empl.core.service.ingest.EmployeeWriter$3
org.bushe.swing.exception.SwingException: Exception handling event topic
event class=im.empl.core.io.parse.impl.Axisgraph78StreamReaderImpl$3,
event=im.empl.core.io.parse.impl.Axisgraph78StreamReaderImpl$3@65770081,
topic=null, eventObj=null
org.bushe.swing.exception.SwingException: Exception handling event topic
event class=im.empl.core.io.parse.impl.Axisgraph78StreamReaderImpl$3,
event=im.empl.core.io.parse.impl.Axisgraph78StreamReaderImpl$3@65770081,
topic=null, eventObj=null
        at
org.bushe.swing.event.ThreadSafeEventService.handleException(ThreadSafeEvent
Service.java:2021)
        at
org.bushe.swing.event.ThreadSafeEventService.handleException(ThreadSafeEvent
Service.java:2009)
        at
org.bushe.swing.event.ThreadSafeEventService.publish(ThreadSafeEventService.
java:975)
        at
org.bushe.swing.event.ThreadSafeEventService.publish(ThreadSafeEventService.
java:904)
        at
blue.core.event.bushe.BusheApplicationEventService.publish(BusheApplicationE
ventService.java:28)
        at
im.empl.core.service.ingest.DefaultEmplIngestManager.ingest(DefaultEmplInges
tManager.java:383)
        at
im.empl.core.service.ingest.AutoEmplIngestMonitor.ingest(AutoEmplIngestMonit
or.java:142)
        at
im.empl.core.service.ingest.AutoEmplIngestMonitor$1.run(AutoEmplIngestMonito
r.java:104)
Caused by: org.hibernate.TransactionException: nested transactions not
supported
        at
org.hibernate.engine.transaction.spi.AbstractTransactionImpl.begin(AbstractT
ransactionImpl.java:152)
        at
org.hibernate.internal.SessionImpl.beginTransaction(SessionImpl.java:1396)
        at
im.empl.core.service.ingest.EmployeeWriter.handleEmployeeSegment(EmployeeWri
ter.java:309)
        at
im.empl.core.service.ingest.EmployeeWriter$3.onEvent(EmployeeWriter.java:116
)
        at
im.empl.core.service.ingest.EmployeeWriter$3.onEvent(EmployeeWriter.java:113
)
        at
org.bushe.swing.event.ThreadSafeEventService.publish(ThreadSafeEventService.
java:971)
        ... 5 more

* Application tier configuration

From core-db.xml:
      <bean id="transactionManager"
class="org.springframework.orm.hibernate3.HibernateTransactionManager">
            <property name="sessionFactory" ref="controlSessionFactory"/>
      </bean>

      <!-- enable the configuration of transactional behavior based on
annotations -->
      <tx:annotation-driven transaction-manager="transactionManager" />

In most cases we are using Spring's HibernateTransactionManager, and
annotations on methods that are transactional. If there is some type of
exception in the method,
the transaction is rolled back automatically.

The Employee ingest behaves a bit differently - it handles transactions
programmatically, for example:

                  Transaction tx = session.beginTransaction();
                  session.save(Employee);
                  tx.commit();

Could it be possible that if an exception is thrown by the session.save()
method that the transaction might not be rolled back or closed, although no
errors pertaining
to this scenario were recorded in the PostgreSQL log.

The TradingWriter makes use of the BatchWriter class, which also handles
transactions programmatically.

Any workarounds to resolve this issue would be greatly appreciated.

thanks


-----Original Message-----
From: Craig Ringer [mailto:ringerc@ringerc.id.au]
Sent: Tuesday, September 18, 2012 12:29 AM
To: Freddie Burgess
Cc: pgsql-bugs@postgresql.org
Subject: Re: [BUGS] Postgres JDBC-hibernate Problem

On 09/18/2012 01:23 AM, Freddie Burgess wrote:
> Thanks Craig,
>
> We were able to make the necessary adjustments to the way Hibernate
> manages the data types differently in version 4.1.6, so we got pass
> this error. Now we have to tackle the a problem with the hibernate
> 4.1.6 batcher process no longer allowing us to ingest data into the
> database. We are getting the "nested transactions not supported
> error", even though the java developers are telling me that they have
> only a single commit at the end of  their logical transaction.

Look at the PostgreSQL logs and see. It's easier to trace if you set
log_line_prefix to something like:

log_line_prefix = '<a=%a,u=%u,db=%d,pid=%p,vtx=%v,tx=%x,cmd=%i>'

which produces significantly more verbose logs but makes it easier to, using
the pid and txix/vtxid info, work out how different logged statements fit
into transactions.

--
Craig Ringer

Re: Postgres JDBC-hibernate Problem

From
Craig Ringer
Date:
On 09/19/2012 03:46 AM, Freddie Burgess wrote:
>
> The Employee ingest behaves a bit differently - it handles transactions
> programmatically, for example:
>
>                    Transaction tx = session.beginTransaction();
>                    session.save(Employee);
>                    tx.commit();
>
> Could it be possible that if an exception is thrown by the session.save()
> method that the transaction might not be rolled back or closed, although no
> errors pertaining to this scenario were recorded in the PostgreSQL log.

It's possible; I don't use Spring, so I can't really say. I know that in
EJB 3.1 container managed transactions with JTA data sources the
guarantees are strong:

- If the exception thrown is annotated @ApplicationException then
   rollback is controlled by that annotation; otherwise:

- If it's an unchecked exception, the transaction is rolled back; and

- If it's a checked exception that's properly declared the transaction
   is NOT rolled back

I don't know what Spring's rules are. It's all a bit localized and
specific to your code, so it's difficult to offer any useful advice at
this point.

If there's any chance you can cook it down to a small, runnable,
self-contained test-case that'd be very useful. In my experience when
I've done so I have, in the process, often found a bug in my code that
was the cause of the problem. When I don't find an issue in my code I
usually have something clear that demonstrates a problem and helps
isolate which project(s) the problem is in.

--
Craig Ringer