hibernate-devel

[Hibernate] JBoss and Hibernate

[Simon S. <sm...@la...>]

Using JBoss 3.0.4, the Apple OS X JDK 1.4DP6 and Postgres 7.2.2 it is 
impossible to persist objects using Hibernate (beta4). When using code 
similar to:

Person p = new Person();
Session sess = Hibernate.openSession();
sess.save( p );  // Exception thrown here
// Close session properly.

The following SQL exception is thrown:

java.sql.SQLException: You cannot commit with autocommit set!

This is ultimately caused by the HiLoGenerator while trying to set the 
persisted object's ID. If I try the same sort of thing with a 
Transaction:

Person p = new Person();
Session sess = Hibernate.openSession();
Transaction tx = sess.beginTransaction();
sess.save( p );  // Exception thrown here
tx.commit();
// Close session properly

The exception:

java.sql.SQLException: You cannot commit during a managed transaction!

is thrown. This is again caused by the HiLoGenerator.

As I had not seen this behaviour under previous versions of JBoss, I 
posted to the JBoss user list asking if anyone else had seen this 
problem. David Jencks, one of the JBoss developers, replied that:

"Autocommit on is required by the jca spec, and should have been the 
case
for 3.0 versions as well.  You should endevour to make the transactions 
be
controlled by the jboss tm/jta/cmt etc."

Which fits with my error messages because I obtain my datasource from 
the JNDI (java:/DefaultDS, if that helps) The problem is that the 
HiLoGenerator (which my classes use) commits the changes that it has 
made to the underlying Hi/Lo table by calling Connection.commit() (line 
131 in HiLoGenerator.java, I think) rather than using a transaction, 
which would work. Are there any known work-arounds to this problem 
other than generating the IDs myself? Should I mark it as a bug on the 
sourceforge pages?

Regards,

Simon

Re: [Hibernate] JBoss and Hibernate

[Max R. A. <ma...@eo...>]

This is expected behavior, snippet from the docs:

hilo.long

Uses a hi/lo algorithm to efficiently generate identifiers of type long,
given a table and column (by default "hibernate_unique_key" and "next"
respectively) as a source of hi values. The hi/lo algorithm generates
identifiers that are unique only for a particular database. Do not use this
generator with connections enlisted with JTA or with a user-supplied
connection.

Notice the last line :)

Workaround: Make your own generator that makes a direct connection to do the
same thing :)

Maybe we should provide such a beast with hibernate ?

/max

----- Original Message -----
From: "Simon Stewart" <sm...@la...>
To: <hib...@li...>
Sent: Friday, November 29, 2002 5:56 PM
Subject: [Hibernate] JBoss and Hibernate


> Using JBoss 3.0.4, the Apple OS X JDK 1.4DP6 and Postgres 7.2.2 it is
> impossible to persist objects using Hibernate (beta4). When using code
> similar to:
>
> Person p = new Person();
> Session sess = Hibernate.openSession();
> sess.save( p );  // Exception thrown here
> // Close session properly.
>
> The following SQL exception is thrown:
>
> java.sql.SQLException: You cannot commit with autocommit set!
>
> This is ultimately caused by the HiLoGenerator while trying to set the
> persisted object's ID. If I try the same sort of thing with a
> Transaction:
>
> Person p = new Person();
> Session sess = Hibernate.openSession();
> Transaction tx = sess.beginTransaction();
> sess.save( p );  // Exception thrown here
> tx.commit();
> // Close session properly
>
> The exception:
>
> java.sql.SQLException: You cannot commit during a managed transaction!
>
> is thrown. This is again caused by the HiLoGenerator.
>
> As I had not seen this behaviour under previous versions of JBoss, I
> posted to the JBoss user list asking if anyone else had seen this
> problem. David Jencks, one of the JBoss developers, replied that:
>
> "Autocommit on is required by the jca spec, and should have been the
> case
> for 3.0 versions as well.  You should endevour to make the transactions
> be
> controlled by the jboss tm/jta/cmt etc."
>
> Which fits with my error messages because I obtain my datasource from
> the JNDI (java:/DefaultDS, if that helps) The problem is that the
> HiLoGenerator (which my classes use) commits the changes that it has
> made to the underlying Hi/Lo table by calling Connection.commit() (line
> 131 in HiLoGenerator.java, I think) rather than using a transaction,
> which would work. Are there any known work-arounds to this problem
> other than generating the IDs myself? Should I mark it as a bug on the
> sourceforge pages?
>
> Regards,
>
> Simon
>
>
>
> -------------------------------------------------------
> This SF.net email is sponsored by: Get the new Palm Tungsten T
> handheld. Power & Color in a compact size!
> http://ads.sourceforge.net/cgi-bin/redirect.pl?palm0002en
> _______________________________________________
> hibernate-devel mailing list
> hib...@li...
> https://lists.sourceforge.net/lists/listinfo/hibernate-devel
>

Re: [Hibernate] JBoss and Hibernate

[Simon S. <sm...@la...>]

On Friday, Nov 29, 2002, at 17:09 Europe/London, Max Rydahl Andersen 
wrote:

> Notice the last line :)

Oh, the shame! I'll just go back and RTFM a little longer. How could I 
have missed that! :)

> Workaround: Make your own generator that makes a direct connection to 
> do the
> same thing :)
>
> Maybe we should provide such a beast with hibernate ?

What immediately springs to mind is the HiLo generator from the OSCore 
Open Symphony package.

Thanks for the swift, accurate and useful reply. And for restraint 
where a harsher type of reply was very much deserved.

Regards,

Simon

Re: [Hibernate] JBoss and Hibernate

[Gavin K. <ga...@ap...>]

Check the Javadoc for HiLoGenerator. It already implements this
functionality. You can supply a JDBC driver class, url, username and
password. Of course, the *correct* way to do this is to have an
implementation of HiLoGenerator that uses a stateless session bean to hand
out hi values. But I don't wan't to start introducing eejaybeez into the
Hibernate source.

> > Workaround: Make your own generator that makes a direct connection to
> > do the
> > same thing :)
> >
> > Maybe we should provide such a beast with hibernate ?