[Hibernate] Connection Handling in Isolater
Hi all,
I think org.hibernate.engine.transaction.Isolater is not handling connections
properly:
The method JdbcDelegate is currently implemented as follows:
public static class JdbcDelegate implements Delegate {
...
public void delegateWork(IsolatedWork work) throws
HibernateException {
Connection connection = null;
try {
connection =
session.getBatcher().openConnection();
...
}
...
}
finally {
if ( wasAutoCommit ) {
try {
connection.setAutoCommit( true
);
}
catch( Throwable ignore ) {
log.trace( "was unable to reset
connection back to auto-commit" );
}
session.getBatcher().closeConnection(
connection );
}
}
}
}
This means that the connection will only be closed if wasAutoCommit==true but I
think it should be closed in any circumstance:
public static class JdbcDelegate implements Delegate {
...
public void delegateWork(IsolatedWork work) throws
HibernateException {
Connection connection = null;
try {
connection =
session.getBatcher().openConnection();
...
}
...
}
finally {
if ( wasAutoCommit ) {
try {
connection.setAutoCommit( true
);
}
catch( Throwable ignore ) {
log.trace( "was unable to reset
connection back to auto-commit" );
}
}
session.getBatcher().closeConnection(
connection );
}
}
}
What do you think ?
--
"Feel free" – 10 GB Mailbox, 100 FreeSMS/Monat ...
Jetzt GMX TopMail testen: http://www.gmx.net/de/go/topmail
-
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys -- and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
___
hibernate-devel mailing list
hibernate-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/hibernate-devel
Re: [Hibernate] Connection Handling in Isolater
I think this is fixed already, have you checked the latest version?
[EMAIL PROTECTED] wrote:
> Hi all,
>
> I think org.hibernate.engine.transaction.Isolater is not handling connections
> properly:
>
> The method JdbcDelegate is currently implemented as follows:
>
> public static class JdbcDelegate implements Delegate {
> ...
> public void delegateWork(IsolatedWork work) throws
> HibernateException {
> Connection connection = null;
> try {
> connection =
> session.getBatcher().openConnection();
> ...
> }
> ...
> }
> finally {
> if ( wasAutoCommit ) {
> try {
> connection.setAutoCommit( true
> );
> }
> catch( Throwable ignore ) {
> log.trace( "was unable to reset
> connection back to auto-commit" );
> }
> session.getBatcher().closeConnection(
> connection );
> }
> }
> }
> }
>
>
> This means that the connection will only be closed if wasAutoCommit==true but
> I think it should be closed in any circumstance:
>
>
> public static class JdbcDelegate implements Delegate {
> ...
> public void delegateWork(IsolatedWork work) throws
> HibernateException {
> Connection connection = null;
> try {
> connection =
> session.getBatcher().openConnection();
> ...
> }
> ...
> }
> finally {
> if ( wasAutoCommit ) {
> try {
> connection.setAutoCommit( true
> );
> }
> catch( Throwable ignore ) {
> log.trace( "was unable to reset
> connection back to auto-commit" );
> }
> }
> session.getBatcher().closeConnection(
> connection );
> }
> }
> }
>
> What do you think ?
>
>
-
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys -- and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
___
hibernate-devel mailing list
hibernate-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/hibernate-devel
Re: [Hibernate] Connection Handling in Isolater
Yep. This has already been fixed for almost two months now in SVN ;)
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of
[EMAIL PROTECTED]
Sent: Thursday, July 20, 2006 8:35 AM
To: hibernate-devel@lists.sourceforge.net
Cc: [EMAIL PROTECTED]
Subject: [Hibernate] Connection Handling in Isolater
Hi all,
I think org.hibernate.engine.transaction.Isolater is not handling
connections properly:
The method JdbcDelegate is currently implemented as follows:
public static class JdbcDelegate implements Delegate {
...
public void delegateWork(IsolatedWork work) throws
HibernateException {
Connection connection = null;
try {
connection =
session.getBatcher().openConnection();
...
}
...
}
finally {
if ( wasAutoCommit ) {
try {
connection.setAutoCommit( true );
}
catch( Throwable ignore ) {
log.trace( "was unable
to reset connection back to auto-commit" );
}
session.getBatcher().closeConnection( connection );
}
}
}
}
This means that the connection will only be closed if
wasAutoCommit==true but I think it should be closed in any circumstance:
public static class JdbcDelegate implements Delegate {
...
public void delegateWork(IsolatedWork work) throws
HibernateException {
Connection connection = null;
try {
connection =
session.getBatcher().openConnection();
...
}
...
}
finally {
if ( wasAutoCommit ) {
try {
connection.setAutoCommit( true );
}
catch( Throwable ignore ) {
log.trace( "was unable
to reset connection back to auto-commit" );
}
}
session.getBatcher().closeConnection(
connection );
}
}
}
What do you think ?
--
"Feel free" - 10 GB Mailbox, 100 FreeSMS/Monat ...
Jetzt GMX TopMail testen: http://www.gmx.net/de/go/topmail
-
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share
your
opinions on IT & business topics through brief surveys -- and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDE
V
___
hibernate-devel mailing list
hibernate-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/hibernate-devel
-
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys -- and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
___
hibernate-devel mailing list
hibernate-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/hibernate-devel
Re: [Hibernate] Connection Handling in Isolater
Hello Steve,
thanks for the quick reply. Since I didn't notice you've moved to SVN I've
checked the "latest" version from CVS (via the web CVS View) ;-)
Rgds
Holger
Steve Ebersole wrote:
>Yep. This has already been fixed for almost two months now in SVN ;)
>
>-Original Message-
>From: [EMAIL PROTECTED]
>[mailto:[EMAIL PROTECTED] On Behalf Of
>[EMAIL PROTECTED]
>Sent: Thursday, July 20, 2006 8:35 AM
>To: hibernate-devel@lists.sourceforge.net
>Cc: [EMAIL PROTECTED]
>Subject: [Hibernate] Connection Handling in Isolater
>
>Hi all,
>
>I think org.hibernate.engine.transaction.Isolater is not handling
>connections properly:
>
>The method JdbcDelegate is currently implemented as follows:
>
> public static class JdbcDelegate implements Delegate {
> ...
> public void delegateWork(IsolatedWork work) throws
>HibernateException {
> Connection connection = null;
> try {
> connection =
>session.getBatcher().openConnection();
> ...
> }
> ...
> }
> finally {
> if ( wasAutoCommit ) {
> try {
>
>connection.setAutoCommit( true );
> }
> catch( Throwable ignore ) {
> log.trace( "was unable
>to reset connection back to auto-commit" );
> }
>
>session.getBatcher().closeConnection( connection );
> }
> }
> }
> }
>
>
>This means that the connection will only be closed if
>wasAutoCommit==true but I think it should be closed in any circumstance:
>
>
> public static class JdbcDelegate implements Delegate {
> ...
> public void delegateWork(IsolatedWork work) throws
>HibernateException {
> Connection connection = null;
> try {
> connection =
>session.getBatcher().openConnection();
> ...
> }
> ...
> }
> finally {
> if ( wasAutoCommit ) {
> try {
>
>connection.setAutoCommit( true );
> }
> catch( Throwable ignore ) {
> log.trace( "was unable
>to reset connection back to auto-commit" );
> }
> }
> session.getBatcher().closeConnection(
>connection );
> }
> }
> }
>
>What do you think ?
>
--
"Feel free" – 10 GB Mailbox, 100 FreeSMS/Monat ...
Jetzt GMX TopMail testen: http://www.gmx.net/de/go/topmail
-
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys -- and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
___
hibernate-devel mailing list
hibernate-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/hibernate-devel
Re: [Hibernate] Connection Handling in Isolater
Hehe. That obviously will not work ;)
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
Sent: Thursday, July 20, 2006 9:13 AM
To: Steve Ebersole
Cc: hibernate-devel@lists.sourceforge.net; [EMAIL PROTECTED]
Subject: Re: [Hibernate] Connection Handling in Isolater
Hello Steve,
thanks for the quick reply. Since I didn't notice you've moved to SVN
I've checked the "latest" version from CVS (via the web CVS View) ;-)
Rgds
Holger
Steve Ebersole wrote:
>Yep. This has already been fixed for almost two months now in SVN ;)
>
>-Original Message-
>From: [EMAIL PROTECTED]
>[mailto:[EMAIL PROTECTED] On Behalf Of
>[EMAIL PROTECTED]
>Sent: Thursday, July 20, 2006 8:35 AM
>To: hibernate-devel@lists.sourceforge.net
>Cc: [EMAIL PROTECTED]
>Subject: [Hibernate] Connection Handling in Isolater
>
>Hi all,
>
>I think org.hibernate.engine.transaction.Isolater is not handling
>connections properly:
>
>The method JdbcDelegate is currently implemented as follows:
>
> public static class JdbcDelegate implements Delegate {
> ...
> public void delegateWork(IsolatedWork work) throws
>HibernateException {
> Connection connection = null;
> try {
> connection =
>session.getBatcher().openConnection();
> ...
> }
> ...
> }
> finally {
> if ( wasAutoCommit ) {
> try {
>
>connection.setAutoCommit( true );
> }
> catch( Throwable ignore ) {
> log.trace( "was unable
>to reset connection back to auto-commit" );
> }
>
>session.getBatcher().closeConnection( connection );
> }
> }
> }
> }
>
>
>This means that the connection will only be closed if
>wasAutoCommit==true but I think it should be closed in any
circumstance:
>
>
> public static class JdbcDelegate implements Delegate {
> ...
> public void delegateWork(IsolatedWork work) throws
>HibernateException {
> Connection connection = null;
> try {
> connection =
>session.getBatcher().openConnection();
> ...
> }
> ...
> }
> finally {
> if ( wasAutoCommit ) {
> try {
>
>connection.setAutoCommit( true );
> }
> catch( Throwable ignore ) {
> log.trace( "was unable
>to reset connection back to auto-commit" );
> }
> }
> session.getBatcher().closeConnection(
>connection );
> }
> }
> }
>
>What do you think ?
>
--
"Feel free" - 10 GB Mailbox, 100 FreeSMS/Monat ...
Jetzt GMX TopMail testen: http://www.gmx.net/de/go/topmail
-
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys -- and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
___
hibernate-devel mailing list
hibernate-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/hibernate-devel
Re: [Hibernate] Roadmap - components
I started down the path of changing the Type interface to have the majority of methods accept a SessionFactoryImplementor. That is something I would like to avoid if possible. Why? Well, this ended up affecting the vast majority of the entire codebase; which in turn meant increasing the footprint of certain often used classes in order to add a reference to the session factory just so they could pass it into these modified Type methods. So that leaves the option of having Types be aware of the session factory. Which upon further reflection is not as bad as it sounds, because really there are only a few Type implementations that even need access to the session factory at all in any of these methods (sqlTypes(), etc exluded). These would be limited to mainly the EntityType subclasses, the ComponentType subclasses, and the CollectionType subclasses. The essential point being that none of the "primitive"/"simple" types are in this category... The one wrinkle in this approach is the various type factory methods on the o.h.Hibernate class. These would need to change signature, or go away. -Original Message- From: Max Andersen Sent: Monday, July 17, 2006 10:51 AM To: Steve Ebersole; Hibernate development Subject: Re: [Hibernate] Roadmap - components point taken. > Well Type and UserType do not necessarily need to be in synch in this > particular regard. We could conceivably change Type and then later > (i.e. as part of a major release) change the UserType API to align it. > After all the whole point of the UserType stuff was to insulate the user > from changes in the underlying Type system... > > -Original Message- > From: Max Andersen > Sent: Monday, July 17, 2006 10:43 AM > To: Steve Ebersole; Hibernate development > Subject: Re: [Hibernate] Roadmap - components > > On Mon, 17 Jul 2006 17:41:25 +0200, Steve Ebersole > <[EMAIL PROTECTED]> wrote: > >> Type is *NOT* a public API... > > but UserType is - don't they need access to this info too ? > > /max > >> >> -Original Message- >> From: Max Andersen >> Sent: Monday, July 17, 2006 10:38 AM >> To: Steve Ebersole; Hibernate development >> Subject: Re: [Hibernate] Roadmap - components >> >> ...but requires changes to public API so probably best suited for 3.3. >> >>> Regarding the component related changes mentioned in the previous >>> email... >>> >>> As I mentioned a lot of the pre-requisite work has already been >>> performed on HEAD. I also took the opportunity to refactor the >>> packaging of the org.hibernate.tuple package. Specifically, most of >> the >>> pre-requisite work was the introduction of the >>> o.h.t.component.ComponentMetamodel class. Currently, ComponentType >> just >>> uses this new class directly. >>> >>> What needs to happen next, then, is for the introduction of a >>> org.hibernate.persister.component.ComponentPersister which is managed >> as >>> part of the session factory much like the other persisters. >>> ComponentType will then need to look up its corresponding >>> ComponentPersister based on a "role name" and use the capabilities of >>> that persister. The pattern here is very similar to >>> EntityType/EntityPersister. The difficulty I ran into though was > that >>> ComponentType would then require access to the session factory (in >> order >>> to locate the persister) from within methods where it is currently > not >>> passed a reference to the session factory (specifically, this was >>> methods like isSame(), isEqual(), compare(), getHashCode(), etc). >> This >>> gets to more general discussions we have had in the past regarding > the >>> scoping of Types. The solution is one of two things: >>> 1) Devise some sort of scoping scheme where Types can unequivocally > be >>> "bound" to a session factory. This is obviously difficult given the >>> current Hibernate.LONG, Hibernate.STRING, etc static references. One >>> thought here would be splitting types (and their interface >>> appropriately) to define "static" Types and "scoped" Types... >>> 2) Modify the Type interface to accept either a session or a session >>> factory/entity mode combo for most methods (would not really matter >> for >>> methods like sqlTypes(), etc) >>> >>> As I mentioned before this then allows us to make the >>> 'hibernate.bytecode.provider' and >>> 'hibernate.bytecode.use_reflection_optimizer'. Down the road, it > also >>> allows us to implement discrimination-based inheritance for >> components. >>> >>> >>> >> > >> - >>> Using Tomcat but need to do more? Need to support web services, >> security? >>> Get stuff done quickly with pre-integrated technology to make your > job >> >>> easier >>> Download IBM WebSphere Application Server v.1.0.1 based on Apache >>> Geronimo >>> >> > http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642 >>> ___ >>> hibernate-devel mailing list >>> hibernate-
[Hibernate] logging AbstractSaveEventListener#performSave
Hi,
I'm trying to debug/fix Hibernate messages like
"org.hibernate.NonUniqueObjectException: a different object with the same
identifier value was already associated with the session: "... and I find the
default exception logging in AbstractSaveEventListener#performSave not
sufficient. I've added some System.err.printlns() with the information I
typically need. It would be great if this debug info would make it somehow into
the latest SVN.
Rgds
Holger
/**
* Ppepares the save call by checking the session caches for a
pre-existing
* entity and performing any lifecycle callbacks.
* @param entity The entity to be saved.
* @param id The id by which to save the entity.
* @param persister The entity's persister instance.
* @param useIdentityColumn Is an identity column in use?
* @param source The session from which the event originated.
* @param requiresImmediateIdAccess does the event context require
* access to the identifier immediately after execution of this method
(if
* not, post-insert style id generators may be postponed if we are
outside
* a transaction).
* @return The id used to save the entity; may be null depending on the
* type of id generator used and the requiresImmediateIdAccess value
* @throws HibernateException
*/
protected Serializable performSave(
Object entity,
Serializable id,
EntityPersister persister,
boolean useIdentityColumn,
Object anything,
EventSource source,
boolean requiresImmediateIdAccess)
throws HibernateException {
if ( log.isTraceEnabled() ) {
log.trace(
"saving " +
MessageHelper.infoString( persister,
id, source.getFactory() )
);
}
EntityKey key;
if ( !useIdentityColumn ) {
key = new EntityKey( id, persister,
source.getEntityMode() );
Object old =
source.getPersistenceContext().getEntity(key);
if (old != null) {
if (
source.getPersistenceContext().getEntry(old).getStatus() == Status.DELETED ) {
source.forceFlush(
source.getPersistenceContext().getEntry(old) );
}
else {
System.err.println("old: " + old);
System.err.println("old.class: " +
old.getClass());
System.err.println("entity: " + entity);
System.err.println("entity.class: " +
entity.getClass());
System.err.println("id: " + id);
throw new NonUniqueObjectException( id,
persister.getEntityName() );
}
}
persister.setIdentifier(entity, id,
source.getEntityMode());
}
else {
key = null;
}
if ( invokeSaveLifecycle(entity, persister, source) ) {
return id; //EARLY EXIT
}
return performSaveOrReplicate(
entity,
key,
persister,
useIdentityColumn,
anything,
source,
requiresImmediateIdAccess
);
}
--
Echte DSL-Flatrate dauerhaft für 0,- Euro*!
"Feel free" mit GMX DSL! http://www.gmx.net/de/go/dsl
-
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys -- and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
___
hibernate-devel mailing list
hibernate-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/hibernate-devel
