hibernate-issues — Hibernate JIRA Notifications

[Hibernate-issues] [Hibernate-JIRA] Created: (HHH-1739) HILO id can cause deadlock: Part deux

[Kirk R. (JIRA) <no...@at...>]

HILO id can cause deadlock: Part deux
-------------------------------------

         Key: HHH-1739
         URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-1739
     Project: Hibernate3
        Type: Bug

  Components: core  
    Versions: 3.1.3    
 Environment: Hibernate 3.1.3 running JDK 1.4.1_07 Solaris 5.8
Adaptive Server Enterprise/12.5.2/EBF 12054 ESD#2/P/Sun_svr4/OS 5.8/ase1252/1844/64-bit/FBO/Thu Aug 12 10:51:11 2004
    Reporter: Kirk Rasmussen


This is mostly a duplicate of HB-1246 but with a twist. I believe that there is a flaw in Hibernate's design for how it generates ids for some dialects. This is a particular problem for deep object graphs and/or at high volume. Or at least it is a problem for those of us stuck on the crappy Sybase platform.

We have an application that creates hundreds of objects that need ids generated within a single transaction. It is quite common for us to potentially exhaust the connection pool with a deep object graph. We are persisting a Trade object which has a complex and deep object graph (upwards of 100s of persistent objects). Within each trade there are roughly 15 classes which need generated ids with 30 or more instances of each class in some cases. 

IMO The design flaw is when the ids are generated. From quickly browsing the source it seems that they are being generated on the fly as the objects are being processed. This can result in running of out database connections when under load or when a particular trade has a large number of persistent object instances and deadlocking the system.

A better design would be if the ids could be generated for all tables in a single transaction up front rather than issuing a whole bunch of individual transactions for each table and object. 

I believe that TOPLink generates all its ids up front to avoid the described resource thrashing. It also has the configuration to generate ids from within the same transaction as the original unit of work or from a secondary unit of work.

See org.hibernate.id.MultipleHiLoPerTableGenerator 

-- 
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.jspa
-
For more information on JIRA, see:
   http://www.atlassian.com/software/jira

[Hibernate-issues] [Hibernate-JIRA] Created: (HHH-1738) Add outer join support to DetachedCriteria API for subcriteria

[Darryl D. (JIRA) <no...@at...>]

Add outer join support to DetachedCriteria API for subcriteria
--------------------------------------------------------------

         Key: HHH-1738
         URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-1738
     Project: Hibernate3
        Type: Patch

  Components: core  
    Versions: 3.1.3    
 Environment: Hibernate-3.1.3 all database platforms
    Reporter: Darryl Dieckman
 Attachments: DetachedCriteria.patch

This is a fix related to an already submitted patch for HHH-1162.   This patch adds the ability to specify a join type for a subcriteria of a DetachedCriteria.  The patch was originall part of a larger patch (HHH-1276) that was not fully applied for some reason.

A quick summary of the problem occurs when a subcriteria is created for a detached criteria.  For example, say you have Foo which has an association to Bar and you want to select all the Foo instances and order by a property of bar.  You might say:

DetachedCriteria criteria = DetachedCriteria.forClass( Foo.class );
criteria.createCriteria( "bar" ).addOrder( Order.asc( "someproperty" ) );

In this case the subcriteria will generate an inner join which could have an adverse effect on the results of the query if the user is expecting Foo's will null Bar references to still be returned.  The patch will allow the user to say:

DetachedCriteria criteria = DetachedCriteria.forClass( Foo.class );
criteria.createCriteria( "bar", JoinFragment.LEFT_OUTER_JOIN ).addOrder( Order.asc( "someproperty" ) );






-- 
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.jspa
-
For more information on JIRA, see:
   http://www.atlassian.com/software/jira

[Hibernate-issues] [Hibernate-JIRA] Commented: (HB-1246) HILO id can cause deadlock

[Kirk R. (JIRA) <no...@at...>]

    [ http://opensource.atlassian.com/projects/hibernate/browse/HB-1246?page=comments#action_23071 ] 

Kirk Rasmussen commented on HB-1246:
------------------------------------

I agree with Bruce.

At what point are ids generated? Are they all created up front when the transaction begins or on the fly as the objects are being processed? I can see this as being a problem if it is done on the fly.  It would be better if ids could be generated for all tables in a single transaction up front rather than a whole bunch of individual transactions for each table and object.

We have an application that creates hundreds of objects that need ids generated within a single transaction. It is quite common for us to potentially exhaust the connection pool with a deep object graph. We are persisting a Trade object which has a complex and deep object graph. Within each trade there are probably 10 classes which need generated ids (Sybase) with 30 or more instances of each class in some cases.



> HILO id can cause deadlock
> --------------------------
>
>          Key: HB-1246
>          URL: http://opensource.atlassian.com/projects/hibernate/browse/HB-1246
>      Project: Hibernate2
>         Type: Bug

>   Components: core
>     Versions: 2.1.6
>  Environment: HILO id generation with a fixed connection limit
>     Reporter: Edward Costello

>
>
> The HILO generator attempts to obtain a connection to the database in addition to the one being used by the current session. If no connections are available and all sessions are attempting an operation that requires ID generation, this will result in deadlock (at least until the connection pool times out the request and the exception kills one of the requesting sessions).
> The simple case to observe this effect is:
> 1) Set up the connection pool to provide only a single connection.
> 2) Attempt to save an object using HILO id generation.
> This issue can also occur when there is more than one connection available.
> E.G if there are 5 connections, 5 threads open a session, all 5 attempt to save. All 5 threads will be blocked while they each try and obtain a connection for the id generator.
> --- Code to Reproduce ---
> Configuration cfg = new Configuration();
> cfg.configure(......); // Configured Pool must only allow 1 connection
> SessionFactory sf = cfg.buildSessionFactory();
> Session s = sf.openSession();
> Transaction tx = s.beginTransaction();
> s.save(new PersistedObject());
> tx.commit();
> ---- Suggested Resolution ---
> The best solution we have come up with is to allow for the configuration of a second smaller connection pool that is used exclusively for HILO (and any other generation types requiring a separate connection).
> This pool would be optional and if not specified the main pool would be used (i.e. the current behaviour).

-- 
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.jspa
-
For more information on JIRA, see:
   http://www.atlassian.com/software/jira

[Hibernate-issues] [Hibernate-JIRA] Created: (HHH-1737) The new BorrowedConnectionProxy prevents users from accessing the native connection

[Nick R. (JIRA) <no...@at...>]

The new BorrowedConnectionProxy prevents users from accessing the native connection
-----------------------------------------------------------------------------------

         Key: HHH-1737
         URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-1737
     Project: Hibernate3
        Type: Bug

  Components: core  
    Versions: 3.1.1, 3.1.2, 3.1.3    
 Environment: Hibernate 3.1.3, Oracle 9.2.0.4
    Reporter: Nick Reid


The borrowConnection functionality now prevents us from accessing the native connection to perform necessary operations (LOB handling, OAQ integration).  Instead of just returning a simple proxy the implements java.sql.Connection the proxy could additionally implement an interface that allows users to access the wrapped connection returned by the ConnectionManager.

i.e.

public interface BorrowedConnection extends java.sql.Connection
{
     java.sql.Connection getTargetConnection()
}

public class BorrowedConnectionProxy implements InvocationHandler {

	private final ConnectionManager connectionManager;
	private boolean useable = true;

	public BorrowedConnectionProxy(ConnectionManager connectionManager) {
		this.connectionManager = connectionManager;
	}

	public Object invoke(Object proxy, Method method, Object[] args) throws Throwable {
		if ( "close".equals( method.getName() ) ) {
			connectionManager.releaseBorrowedConnection();
			return null;
		}
		if ( "getTargetConnection".equals( method.getName() ) ) {
			return connectionManager.getConnection();
		}
		// should probably no-op commit/rollback here, at least in JTA scenarios
		if ( !useable ) {
			throw new HibernateException( "connnection proxy not usable after transaction completion" );
		}
		try {
			return method.invoke( connectionManager.getConnection(), args );
		}
		catch( InvocationTargetException e ) {
			throw e.getTargetException();
		}
	}

	public static Connection generateProxy(ConnectionManager connectionManager) {
		BorrowedConnectionProxy handler = new BorrowedConnectionProxy( connectionManager );
		return ( Connection ) Proxy.newProxyInstance(
				Connection.class.getClassLoader(),
		        new Class[] { BorrowedConnection.class },
		        handler
		);
	}

	public static void renderUnuseable(Connection connection) {
		if ( connection != null && Proxy.isProxyClass( connection.getClass() ) ) {
			InvocationHandler handler = Proxy.getInvocationHandler( connection );
			if ( BorrowedConnectionProxy.class.isAssignableFrom( handler.getClass() ) ) {
				( ( BorrowedConnectionProxy ) handler ).useable = false;
			}
		}
	}
}

We could always get access to the connectionManager field of the invocation handler via reflection, but this is not supportable or maintainable.

-- 
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.jspa
-
For more information on JIRA, see:
   http://www.atlassian.com/software/jira

[Hibernate-issues] [Hibernate-JIRA] Commented: (HHH-1736) Associations based on multiple columns/composite keys is not possible to load with native sql query

[Max R. A. (JIRA) <no...@at...>]

    [ http://opensource.atlassian.com/projects/hibernate/browse/HHH-1736?page=comments#action_23070 ] 

Max Rydahl Andersen commented on HHH-1736:
------------------------------------------

Now I remember why this is not supported (yet).

For single-column joins we have {col_alias.element} which will be replaced with the join alias.
The issue occurs when you have multiple column, now there is no real alias name to use since
we need multiple names.

I suggest that we allow something like:
{col_alias.element[0]}
{col_alias.element[1]}

or 

{col_alias.element.0}
{col_alias.element.1}



> Associations based on multiple columns/composite keys is not possible to load with native sql query
> ---------------------------------------------------------------------------------------------------
>
>          Key: HHH-1736
>          URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-1736
>      Project: Hibernate3
>         Type: Bug

>   Components: core
>     Versions: 3.2.0.cr2
>     Reporter: Max Rydahl Andersen
>     Assignee: Max Rydahl Andersen
>     Priority: Critical

>
>


-- 
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.jspa
-
For more information on JIRA, see:
   http://www.atlassian.com/software/jira

[Hibernate-issues] [Hibernate-JIRA] Assigned: (HHH-1736) Associations based on multiple columns/composite keys is not possible to load with native sql query

[Max R. A. (JIRA) <no...@at...>]

     [ http://opensource.atlassian.com/projects/hibernate/browse/HHH-1736?page=all ]

Max Rydahl Andersen reassigned HHH-1736:
----------------------------------------

    Assign To: Max Rydahl Andersen

> Associations based on multiple columns/composite keys is not possible to load with native sql query
> ---------------------------------------------------------------------------------------------------
>
>          Key: HHH-1736
>          URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-1736
>      Project: Hibernate3
>         Type: Bug

>   Components: core
>     Versions: 3.2.0.cr2
>     Reporter: Max Rydahl Andersen
>     Assignee: Max Rydahl Andersen
>     Priority: Critical

>
>


-- 
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.jspa
-
For more information on JIRA, see:
   http://www.atlassian.com/software/jira

[Hibernate-issues] [Hibernate-JIRA] Resolved: (ANN-340) Hard dependency to CGLIB classes in mustBeSkipped()

[Emmanuel B. (JIRA) <no...@at...>]

     [ http://opensource.atlassian.com/projects/hibernate/browse/ANN-340?page=all ]
     
Emmanuel Bernard resolved ANN-340:
----------------------------------

    Resolution: Fixed

> Hard dependency to CGLIB classes in mustBeSkipped()
> ---------------------------------------------------
>
>          Key: ANN-340
>          URL: http://opensource.atlassian.com/projects/hibernate/browse/ANN-340
>      Project: Hibernate Annotations
>         Type: Bug

>   Components: binder
>     Versions: 3.1.0.Beta10
>     Reporter: Emmanuel Bernard
>     Assignee: Emmanuel Bernard
>      Fix For: 3.2.0.cr1

>
>


-- 
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.jspa
-
For more information on JIRA, see:
   http://www.atlassian.com/software/jira

[Hibernate-issues] [Hibernate-JIRA] Created: (ANN-340) Hard dependency to CGLIB classes in mustBeSkipped()

[Emmanuel B. (JIRA) <no...@at...>]

Hard dependency to CGLIB classes in mustBeSkipped()
---------------------------------------------------

         Key: ANN-340
         URL: http://opensource.atlassian.com/projects/hibernate/browse/ANN-340
     Project: Hibernate Annotations
        Type: Bug

  Components: binder  
    Versions: 3.1.0.Beta10    
    Reporter: Emmanuel Bernard
 Assigned to: Emmanuel Bernard 
     Fix For: 3.2.0.cr1




-- 
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.jspa
-
For more information on JIRA, see:
   http://www.atlassian.com/software/jira

[Hibernate-issues] [Hibernate-JIRA] Created: (HHH-1736) Associations based on multiple columns/composite keys is not possible to load with native sql query

[Max R. A. (JIRA) <no...@at...>]

Associations based on multiple columns/composite keys is not possible to load with native sql query
---------------------------------------------------------------------------------------------------

         Key: HHH-1736
         URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-1736
     Project: Hibernate3
        Type: Bug

  Components: core  
    Versions: 3.2.0.cr2    
    Reporter: Max Rydahl Andersen
    Priority: Critical




-- 
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.jspa
-
For more information on JIRA, see:
   http://www.atlassian.com/software/jira

[Hibernate-issues] [Hibernate-JIRA] Closed: (HHH-1735) From, [hibernate 3 XML-Relational Persitence] the method which creates .....

[Christian B. (JIRA) <no...@at...>]

     [ http://opensource.atlassian.com/projects/hibernate/browse/HHH-1735?page=all ]
     
Christian Bauer closed HHH-1735:
--------------------------------

    Resolution: Rejected

http://forum.hibernate.org/


> From, [hibernate 3 XML-Relational Persitence] the method which creates .....
> ----------------------------------------------------------------------------
>
>          Key: HHH-1735
>          URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-1735
>      Project: Hibernate3
>         Type: New Feature

>     Versions: 3.1.3
>  Environment: hibernate 3.1.3 
>     Reporter: kim
>     Priority: Minor

>
>
> Help me please .
> From, [hibernate 3 XML-Relational Persitence] the method which creates 
> 1.It wants knowing -> The method which creates FACTORY.SESSION   
>      (Session session = factory.openSession ();) 
> 2. It wants knowing ->  hibernate.cfg.xml drawing up methods 
> 3.Sample
>   3.1 XML DATA -> product.xml
>     <products>
>         <procusts prod_id = "1">
>               <list_a>A</>
>               <list_b>B</>
>     </products>            
>   3.2 hibernate.cfg.xml ->??????     
>   3.3 POJO (xml,java) ->??????    
>   3.4 Bean (java)->??????  
> ThankYou.
> Please help me !(jaehyunkim148@ hanmail.net)

-- 
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.jspa
-
For more information on JIRA, see:
   http://www.atlassian.com/software/jira

[Hibernate-issues] [Hibernate-JIRA] Created: (HHH-1735) From, [hibernate 3 XML-Relational Persitence] the method which creates .....

[kim (JIRA) <no...@at...>]

From, [hibernate 3 XML-Relational Persitence] the method which creates .....
----------------------------------------------------------------------------

         Key: HHH-1735
         URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-1735
     Project: Hibernate3
        Type: New Feature

    Versions: 3.1.3    
 Environment: hibernate 3.1.3 
    Reporter: kim
    Priority: Minor


Help me please .
From, [hibernate 3 XML-Relational Persitence] the method which creates 

1.It wants knowing -> The method which creates FACTORY.SESSION   
     (Session session = factory.openSession ();) 

2. It wants knowing ->  hibernate.cfg.xml drawing up methods 

3.Sample
  3.1 XML DATA -> product.xml
    <products>
        <procusts prod_id = "1">
              <list_a>A</>
              <list_b>B</>
    </products>            

  3.2 hibernate.cfg.xml ->??????     
  3.3 POJO (xml,java) ->??????    
  3.4 Bean (java)->??????  

ThankYou.
Please help me !(jaehyunkim148@ hanmail.net)

-- 
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.jspa
-
For more information on JIRA, see:
   http://www.atlassian.com/software/jira

[Hibernate-issues] [Hibernate-JIRA] Commented: (HHH-1713) AbstractEntityPersister causes an exception when a row in a joined table is missing with fetch="select"

[Serge P. N. (JIRA) <no...@at...>]

    [ http://opensource.atlassian.com/projects/hibernate/browse/HHH-1713?page=comments#action_23060 ] 

Serge P. Nekoval commented on HHH-1713:
---------------------------------------

Hi,

I've generated a patch for Hibernate 3.0.5, since we're unable to upgrade to 3.1 so far. Attached.
Seems to work fine.

> AbstractEntityPersister causes an exception when a row in a joined table is missing with fetch="select"
> -------------------------------------------------------------------------------------------------------
>
>          Key: HHH-1713
>          URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-1713
>      Project: Hibernate3
>         Type: Bug

>   Components: core
>     Versions: 3.1.3, 3.2.0 cr1
>  Environment: Hibernate 3.1.3, 3.2.0cr1
> Oracle 9i (using odjbc14.jar from Oracle 10.1.0.4)
>     Reporter: Mike Dillon
>     Priority: Minor
>  Attachments: AbstractEntityPersister.java.patch, BasicEntityPersister.patch
>
>
> When using the <join> mapping, the behavior of AbstractEntityPersister when the joined row is missing is not consistent between fetch="join" and fetch="select".
> When fetch="join" and the row is missing, the AbstractEntityPersister simply sets all the outer joined fields to null since that's what comes back from the database. However, when fetch="select" and the row is missing, an SQLException is thrown. The reason is that the call to ResultSet.next() is not checked to see if a row is available before calling ResultSet.getXXXX(). In our Oracle enviroment, this resulted in a cryptic JDBC error about an "Exhausted Resultset".
> The fix is to check the return value of ResultSet.next(). I have attached a patch with a proposed fix for this issue. To be consistent with the current behavior of fetch="join", it explicitly sets all fields that come from the "sequential select" to null when the select does not produce any rows. This contradicts the hibernate-mapping DTD which says that the "optional" attribute on <join> defaults to false, but since that attribute is undocumented and the current implementation doesn't seem to respect this attribute even when fetch="join", I decided to be consistent with the actual semantics of fetch="join".
> The behavior of the optional attibute probably needs to be fixed in both cases, but I didn't address that with my patch. It seems that optional only works as advertised when Hibernate is able to produce a query with a single polymorphic join and can use an inner join instead of a left outer join.
> My patch was created against Hibernate 3.1.3, but I looked at the same code in 3.2.0cr1 and it has not changed.

-- 
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.jspa
-
For more information on JIRA, see:
   http://www.atlassian.com/software/jira

[Hibernate-issues] [Hibernate-JIRA] Updated: (HHH-1713) AbstractEntityPersister causes an exception when a row in a joined table is missing with fetch="select"

[Serge P. N. (JIRA) <no...@at...>]

     [ http://opensource.atlassian.com/projects/hibernate/browse/HHH-1713?page=all ]

Serge P. Nekoval updated HHH-1713:
----------------------------------

    Attachment: BasicEntityPersister.patch

> AbstractEntityPersister causes an exception when a row in a joined table is missing with fetch="select"
> -------------------------------------------------------------------------------------------------------
>
>          Key: HHH-1713
>          URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-1713
>      Project: Hibernate3
>         Type: Bug

>   Components: core
>     Versions: 3.1.3, 3.2.0 cr1
>  Environment: Hibernate 3.1.3, 3.2.0cr1
> Oracle 9i (using odjbc14.jar from Oracle 10.1.0.4)
>     Reporter: Mike Dillon
>     Priority: Minor
>  Attachments: AbstractEntityPersister.java.patch, BasicEntityPersister.patch
>
>
> When using the <join> mapping, the behavior of AbstractEntityPersister when the joined row is missing is not consistent between fetch="join" and fetch="select".
> When fetch="join" and the row is missing, the AbstractEntityPersister simply sets all the outer joined fields to null since that's what comes back from the database. However, when fetch="select" and the row is missing, an SQLException is thrown. The reason is that the call to ResultSet.next() is not checked to see if a row is available before calling ResultSet.getXXXX(). In our Oracle enviroment, this resulted in a cryptic JDBC error about an "Exhausted Resultset".
> The fix is to check the return value of ResultSet.next(). I have attached a patch with a proposed fix for this issue. To be consistent with the current behavior of fetch="join", it explicitly sets all fields that come from the "sequential select" to null when the select does not produce any rows. This contradicts the hibernate-mapping DTD which says that the "optional" attribute on <join> defaults to false, but since that attribute is undocumented and the current implementation doesn't seem to respect this attribute even when fetch="join", I decided to be consistent with the actual semantics of fetch="join".
> The behavior of the optional attibute probably needs to be fixed in both cases, but I didn't address that with my patch. It seems that optional only works as advertised when Hibernate is able to produce a query with a single polymorphic join and can use an inner join instead of a left outer join.
> My patch was created against Hibernate 3.1.3, but I looked at the same code in 3.2.0cr1 and it has not changed.

-- 
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.jspa
-
For more information on JIRA, see:
   http://www.atlassian.com/software/jira

[Hibernate-issues] [Hibernate-JIRA] Closed: (HHH-1452) Native SQL query is missing join if entity includes many-to-one on secondary table

[Max R. A. (JIRA) <no...@at...>]

     [ http://opensource.atlassian.com/projects/hibernate/browse/HHH-1452?page=all ]
     
Max Rydahl Andersen closed HHH-1452:
------------------------------------

    Fix Version: 3.2.0
     Resolution: Fixed

fixed afaik. 

just need to use <return-join>.

> Native SQL query is missing join if entity includes many-to-one on secondary table
> ----------------------------------------------------------------------------------
>
>          Key: HHH-1452
>          URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-1452
>      Project: Hibernate3
>         Type: Bug

>   Components: core
>     Versions: 3.1.2
>     Reporter: Christian Bauer
>     Priority: Minor
>      Fix For: 3.2.0

>
>
> Mapping of a many-to-one across a join table:
> <class name="Item">
>     <join table="ITEM_BUYER"
>           optional="true">
>         <key column="ITEM_ID"/>
>         <many-to-one name="buyer" column="USER_ID"/>
>     </join>
> </class>
> Query:
>         result = session.createSQLQuery("select {i.*} from ITEM i" +
>                                         " join USERS u on i.SELLER_ID = u.USER_ID" +
>                                         " where u.USERNAME = :uname")
>                          .addEntity("i", Item.class)
>                          .setParameter("uname", "turin")
>                          .list();
> Generated SQL and exception:
> Hibernate: 
>     /* dynamic native SQL query */ select
>         i.ITEM_ID as ITEM1_7_0_,
>         i.OBJ_VERSION as OBJ2_7_0_,
>         i.NAME as NAME7_0_,
>         i.DESCRIPTION as DESCRIPT4_7_0_,
>         i.INITIAL_PRICE as INITIAL5_7_0_,
>         i.INITIAL_PRICE_CURRENCY as INITIAL6_7_0_,
>         i.RESERVE_PRICE as RESERVE7_7_0_,
>         i.RESERVE_PRICE_CURRENCY as RESERVE8_7_0_,
>         i.START_DATE as START9_7_0_,
>         i.END_DATE as END10_7_0_,
>         i.STATE as STATE7_0_,
>         i.APPROVAL_DATETIME as APPROVAL12_7_0_,
>         i.CREATED as CREATED7_0_,
>         i.APPROVED_BY_USER_ID as APPROVED14_7_0_,
>         i.SELLER_ID as SELLER15_7_0_,
>         i_1_.USER_ID as USER2_2_0_,
>         'T' as formula0_0_,
>         i.ITEM_ID as formula1_0_ 
>     from
>         ITEM i 
>     join
>         USERS u 
>             on i.SELLER_ID = u.USER_ID 
>     where
>         u.USERNAME = ?
> 03:45:18,243  WARN JDBCExceptionReporter:71 - SQL Error: -28, SQLState: S0022
> 03:45:18,244 ERROR JDBCExceptionReporter:72 - Column not found: I_1_.USER_ID in statement [/* dynamic native SQL query */ select i.ITEM_ID as ITEM1_7_0_, i.OBJ_VERSION as OBJ2_7_0_, i.NAME as NAME7_0_, i.DESCRIPTION as DESCRIPT4_7_0_, i.INITIAL_PRICE as INITIAL5_7_0_, i.INITIAL_PRICE_CURRENCY as INITIAL6_7_0_, i.RESERVE_PRICE as RESERVE7_7_0_, i.RESERVE_PRICE_CURRENCY as RESERVE8_7_0_, i.START_DATE as START9_7_0_, i.END_DATE as END10_7_0_, i.STATE as STATE7_0_, i.APPROVAL_DATETIME as APPROVAL12_7_0_, i.CREATED as CREATED7_0_, i.APPROVED_BY_USER_ID as APPROVED14_7_0_, i.SELLER_ID as SELLER15_7_0_, i_1_.USER_ID as USER2_2_0_, 'T' as formula0_0_, i.ITEM_ID as formula1_0_ from ITEM i join USERS u on i.SELLER_ID = u.USER_ID where u.USERNAME = ?]

-- 
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.jspa
-
For more information on JIRA, see:
   http://www.atlassian.com/software/jira

[Hibernate-issues] [Hibernate-JIRA] Resolved: (HHH-1734) Connection leak when using hilo strategy in SE environment

[Emmanuel B. (JIRA) <no...@at...>]

     [ http://opensource.atlassian.com/projects/hibernate/browse/HHH-1734?page=all ]
     
Emmanuel Bernard resolved HHH-1734:
-----------------------------------

    Fix Version: 3.2.0
     Resolution: Fixed

> Connection leak when using hilo strategy in SE environment
> ----------------------------------------------------------
>
>          Key: HHH-1734
>          URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-1734
>      Project: Hibernate3
>         Type: Bug

>   Components: core
>     Versions: 3.2.0.cr2
>     Reporter: Emmanuel Bernard
>     Assignee: Emmanuel Bernard
>      Fix For: 3.2.0

>
>


-- 
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.jspa
-
For more information on JIRA, see:
   http://www.atlassian.com/software/jira

[Hibernate-issues] [Hibernate-JIRA] Created: (HHH-1734) Connection leak when using hilo strategy in SE environment

[Emmanuel B. (JIRA) <no...@at...>]

Connection leak when using hilo strategy in SE environment
----------------------------------------------------------

         Key: HHH-1734
         URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-1734
     Project: Hibernate3
        Type: Bug

  Components: core  
    Versions: 3.2.0.cr2    
    Reporter: Emmanuel Bernard
 Assigned to: Emmanuel Bernard 




-- 
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.jspa
-
For more information on JIRA, see:
   http://www.atlassian.com/software/jira

[Hibernate-issues] [Hibernate-JIRA] Commented: (HHH-1714) Session.get() behavior

[Lars T. (JIRA) <no...@at...>]

    [ http://opensource.atlassian.com/projects/hibernate/browse/HHH-1714?page=comments#action_23058 ] 

Lars Torunski commented on HHH-1714:
------------------------------------

Steve, 3.2.0 isn't released yet, but this issue is fixed in 3.2.1?

> Session.get() behavior
> ----------------------
>
>          Key: HHH-1714
>          URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-1714
>      Project: Hibernate3
>         Type: Bug

>   Components: core
>     Reporter: Steve Ebersole
>     Assignee: Steve Ebersole
>      Fix For: 3.2.1

>
>
> The behavior of Session.get() should be as follows:
> 1) if the entity to get is already associated with the session:
> a) as a proxy, return the proxy making sure it gets initialized (potentially resulting in a ONFE)
> b) as a naked entity, return that entity
> 2) if the entity to get is not already associated with the session, attempt to load it either returning null if not found or the "naked" loaded entity
> Currently (1.a) is messed up in that the proxy is returned but not forced to initialize

-- 
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.jspa
-
For more information on JIRA, see:
   http://www.atlassian.com/software/jira

[Hibernate-issues] [Hibernate-JIRA] Resolved: (HHH-1733) JDBC Connection Closed Exception

[Emmanuel B. (JIRA) <no...@at...>]

     [ http://opensource.atlassian.com/projects/hibernate/browse/HHH-1733?page=all ]
     
Emmanuel Bernard resolved HHH-1733:
-----------------------------------

    Resolution: Rejected

go to the user forum

> JDBC Connection Closed Exception 
> ---------------------------------
>
>          Key: HHH-1733
>          URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-1733
>      Project: Hibernate3
>         Type: Bug

>     Versions: 3.0 final
>  Environment: Hibernate Version 3.0
> JBoss 3.2.3
> Linux 2.4.9-e.49enterprise
> Oracle 9i
>     Reporter: srinath ramachandran

>
>
> When My database is restarted and I don't restart my application server and try to query using Hibernate. I get the below mentioned exception. It looks like Hibernate still uses the cached connection.  
> My Hibernate properties :
> hibernate.dialect=org.hibernate.dialect.OracleDialect
> transaction.factory_class=org.hibernate.transaction.JDBCTransactionFactory
> hibernate.cache.provider_class=org.hibernate.cache.HashtableCacheProvider
> hibernate.cglib.use_reflection_optimizer=false
> hibernate.show_sql=true
> hibernate.use_identifer_rollback=true
> Exception : 
> Caused by: java.sql.SQLException: Closed Connection
>         at oracle.jdbc.dbaccess.DBError.throwSqlException(DBError.java:134)
>         at oracle.jdbc.dbaccess.DBError.throwSqlException(DBError.java:179)
>         at oracle.jdbc.dbaccess.DBError.throwSqlException(DBError.java:269)
>         at oracle.jdbc.driver.OracleConnection.privatePrepareStatement(OracleConnection.java:962)
>         at oracle.jdbc.driver.OracleConnection.prepareStatement(OracleConnection.java:869)
>         at org.hibernate.jdbc.AbstractBatcher.getPreparedStatement(AbstractBatcher.java:396)
>         at org.hibernate.jdbc.AbstractBatcher.getPreparedStatement(AbstractBatcher.java:334)
>         at org.hibernate.jdbc.AbstractBatcher.prepareQueryStatement(AbstractBatcher.java:88)
>         at org.hibernate.loader.Loader.prepareQueryStatement(Loader.java:1162)
>         at org.hibernate.loader.Loader.doQuery(Loader.java:390)
>         at org.hibernate.loader.Loader.doQueryAndInitializeNonLazyCollections(Loader.java:218)
>         at org.hibernate.loader.Loader.doList(Loader.java:1593)

-- 
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.jspa
-
For more information on JIRA, see:
   http://www.atlassian.com/software/jira

[Hibernate-issues] [Hibernate-JIRA] Created: (HHH-1733) JDBC Connection Closed Exception

[srinath r. (JIRA) <no...@at...>]

JDBC Connection Closed Exception 
---------------------------------

         Key: HHH-1733
         URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-1733
     Project: Hibernate3
        Type: Bug

    Versions: 3.0 final    
 Environment: Hibernate Version 3.0
JBoss 3.2.3
Linux 2.4.9-e.49enterprise
Oracle 9i
    Reporter: srinath ramachandran


When My database is restarted and I don't restart my application server and try to query using Hibernate. I get the below mentioned exception. It looks like Hibernate still uses the cached connection.  

My Hibernate properties :
hibernate.dialect=org.hibernate.dialect.OracleDialect
transaction.factory_class=org.hibernate.transaction.JDBCTransactionFactory
hibernate.cache.provider_class=org.hibernate.cache.HashtableCacheProvider
hibernate.cglib.use_reflection_optimizer=false
hibernate.show_sql=true
hibernate.use_identifer_rollback=true

Exception : 
Caused by: java.sql.SQLException: Closed Connection
        at oracle.jdbc.dbaccess.DBError.throwSqlException(DBError.java:134)
        at oracle.jdbc.dbaccess.DBError.throwSqlException(DBError.java:179)
        at oracle.jdbc.dbaccess.DBError.throwSqlException(DBError.java:269)
        at oracle.jdbc.driver.OracleConnection.privatePrepareStatement(OracleConnection.java:962)
        at oracle.jdbc.driver.OracleConnection.prepareStatement(OracleConnection.java:869)
        at org.hibernate.jdbc.AbstractBatcher.getPreparedStatement(AbstractBatcher.java:396)
        at org.hibernate.jdbc.AbstractBatcher.getPreparedStatement(AbstractBatcher.java:334)
        at org.hibernate.jdbc.AbstractBatcher.prepareQueryStatement(AbstractBatcher.java:88)
        at org.hibernate.loader.Loader.prepareQueryStatement(Loader.java:1162)
        at org.hibernate.loader.Loader.doQuery(Loader.java:390)
        at org.hibernate.loader.Loader.doQueryAndInitializeNonLazyCollections(Loader.java:218)
        at org.hibernate.loader.Loader.doList(Loader.java:1593)


-- 
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.jspa
-
For more information on JIRA, see:
   http://www.atlassian.com/software/jira

[Hibernate-issues] [Hibernate-JIRA] Commented: (HHH-1713) AbstractEntityPersister causes an exception when a row in a joined table is missing with fetch="select"

[Mike D. (JIRA) <no...@at...>]

    [ http://opensource.atlassian.com/projects/hibernate/browse/HHH-1713?page=comments#action_23056 ] 

Mike Dillon commented on HHH-1713:
----------------------------------

This also affects the 3.2.0cr2 release, since the code in question is unchanged.

> AbstractEntityPersister causes an exception when a row in a joined table is missing with fetch="select"
> -------------------------------------------------------------------------------------------------------
>
>          Key: HHH-1713
>          URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-1713
>      Project: Hibernate3
>         Type: Bug

>   Components: core
>     Versions: 3.1.3, 3.2.0 cr1
>  Environment: Hibernate 3.1.3, 3.2.0cr1
> Oracle 9i (using odjbc14.jar from Oracle 10.1.0.4)
>     Reporter: Mike Dillon
>     Priority: Minor
>  Attachments: AbstractEntityPersister.java.patch
>
>
> When using the <join> mapping, the behavior of AbstractEntityPersister when the joined row is missing is not consistent between fetch="join" and fetch="select".
> When fetch="join" and the row is missing, the AbstractEntityPersister simply sets all the outer joined fields to null since that's what comes back from the database. However, when fetch="select" and the row is missing, an SQLException is thrown. The reason is that the call to ResultSet.next() is not checked to see if a row is available before calling ResultSet.getXXXX(). In our Oracle enviroment, this resulted in a cryptic JDBC error about an "Exhausted Resultset".
> The fix is to check the return value of ResultSet.next(). I have attached a patch with a proposed fix for this issue. To be consistent with the current behavior of fetch="join", it explicitly sets all fields that come from the "sequential select" to null when the select does not produce any rows. This contradicts the hibernate-mapping DTD which says that the "optional" attribute on <join> defaults to false, but since that attribute is undocumented and the current implementation doesn't seem to respect this attribute even when fetch="join", I decided to be consistent with the actual semantics of fetch="join".
> The behavior of the optional attibute probably needs to be fixed in both cases, but I didn't address that with my patch. It seems that optional only works as advertised when Hibernate is able to produce a query with a single polymorphic join and can use an inner join instead of a left outer join.
> My patch was created against Hibernate 3.1.3, but I looked at the same code in 3.2.0cr1 and it has not changed.

-- 
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.jspa
-
For more information on JIRA, see:
   http://www.atlassian.com/software/jira

[Hibernate-issues] [Hibernate-JIRA] Commented: (HHH-1731) configuration.setProperty("connection.url", newJdbcUrl) fails

[Per L. (JIRA) <no...@at...>]

    [ http://opensource.atlassian.com/projects/hibernate/browse/HHH-1731?page=comments#action_23055 ] 

Per Lindberg commented on HHH-1731:
-----------------------------------

The basic problem appears to be that the property names
specfied in the file read by .configure(cfgFilename) may be
abbreviated (e.g. "connection.url" for "hibernate.connection.url")
but NOT in the parameter to .setProperty!

This should IMHO be fixed either by adding the same ability
to expand an abbreviated property name to .setProperty
(in the same way as .configure), or documenting the difference
of behaviour in the JavaDoc. (It wouldn't hurt to make the JavaDoc
more complete on this issue in any case).



> configuration.setProperty("connection.url", newJdbcUrl) fails
> -------------------------------------------------------------
>
>          Key: HHH-1731
>          URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-1731
>      Project: Hibernate3
>         Type: Bug

>   Components: core
>     Versions: 3.1.2
>  Environment: WinXP, Tomcat 5.5, MySQL 5, Hibernate 3.1.2
>     Reporter: Per Lindberg
>  Attachments: HibernateDatabase.java
>
> Original Estimate: 1 hour
>         Remaining: 1 hour
>
> It appears that, after
>    Configuration configuration = new Configuration().configure(cfgFileName);
> but before
>    new SchemaExport(configuration).create(false,true);
>    sessionFactory = configuration.buildSessionFactory()
> the JDBC Connection URL can't be changed with
> configuration.setProperty("connection.url", newJdbcUrl)
> Trying to do so causes configuration.getProperty to return the new value,
> but the SessionFactory gets confused and appears to use the old value.
> I have the impression that configure(cfgFileName) sets the properties
> of the Configuration in some "hard" way, so that later calls to setProperty
> are mostly ignored (except that getProperty returns the new value).
> The attached file attempts to do this, and fails.

-- 
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.jspa
-
For more information on JIRA, see:
   http://www.atlassian.com/software/jira

[Hibernate-issues] [Hibernate-JIRA] Resolved: (HHH-1732) EhCache.toMap still assumes Serializable objects

[Emmanuel B. (JIRA) <no...@at...>]

     [ http://opensource.atlassian.com/projects/hibernate/browse/HHH-1732?page=all ]
     
Emmanuel Bernard resolved HHH-1732:
-----------------------------------

    Resolution: Fixed

> EhCache.toMap still assumes Serializable objects
> ------------------------------------------------
>
>          Key: HHH-1732
>          URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-1732
>      Project: Hibernate3
>         Type: Bug

>   Components: core
>     Versions: 3.2.0.cr2
>     Reporter: Emmanuel Bernard
>     Assignee: Emmanuel Bernard
>     Priority: Trivial
>      Fix For: 3.2.0

>
>


-- 
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.jspa
-
For more information on JIRA, see:
   http://www.atlassian.com/software/jira

[Hibernate-issues] [Hibernate-JIRA] Created: (HHH-1732) EhCache.toMap still assumes Serializable objects

[Emmanuel B. (JIRA) <no...@at...>]

EhCache.toMap still assumes Serializable objects
------------------------------------------------

         Key: HHH-1732
         URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-1732
     Project: Hibernate3
        Type: Bug

  Components: core  
    Versions: 3.2.0.cr2    
    Reporter: Emmanuel Bernard
 Assigned to: Emmanuel Bernard 
    Priority: Trivial
     Fix For: 3.2.0




-- 
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.jspa
-
For more information on JIRA, see:
   http://www.atlassian.com/software/jira

[Hibernate-issues] [Hibernate-JIRA] Resolved: (EJB-176) Generated link table contains non nullable ids

[Emmanuel B. (JIRA) <no...@at...>]

     [ http://opensource.atlassian.com/projects/hibernate/browse/EJB-176?page=all ]
     
Emmanuel Bernard resolved EJB-176:
----------------------------------

    Resolution: Rejected

Explicitly define the association table name in such a case

> Generated link table contains non nullable ids
> ----------------------------------------------
>
>          Key: EJB-176
>          URL: http://opensource.atlassian.com/projects/hibernate/browse/EJB-176
>      Project: Hibernate Entity Manager
>         Type: Bug

>   Components: EntityManager
>     Versions: 3.1.0.Beta8
>  Environment: Derby database.
> Hibernate 3.2.0cr1 (cr2 could not work at all it seems)
>     Reporter: Christof Ameye
>     Priority: Blocker

>
>
> I have an entity A containing two lists (@OneToMany) relations to two different entity types B3 and B23, but both of these entity types are derived from the same persistable entity type Bp1. So both entity types arrive in the same table for Bp1.
> When automatically generating the tables (the persistence.xml property 'hibernate.hbm2ddl.auto' is set to 'create-drop').
> It seems it creates a link table containing 3 columns with 'A_ID', 'B3_ID' and 'B23_ID'.
> Persisting always fails:
> One entry in the table contains always an entry in column A_ID, but in the other columns there is always only one filled in (should). But any insert always fails, because there is always one of the columns null, but the table definition does not allow nulls; (it contains a link either to entity of type B3 or to entity of type B23).
> I suppose I hit a bug ?
> Hibernate 3.2CR1 with the latests annotations and entity manager. Using a Derby database.

-- 
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.jspa
-
For more information on JIRA, see:
   http://www.atlassian.com/software/jira

[Hibernate-issues] [Hibernate-JIRA] Commented: (HHH-1731) configuration.setProperty("connection.url", newJdbcUrl) fails

[Per L. (JIRA) <no...@at...>]

    [ http://opensource.atlassian.com/projects/hibernate/browse/HHH-1731?page=comments#action_23053 ] 

Per Lindberg commented on HHH-1731:
-----------------------------------

By the way: in the attached example, the calls to

boolean dbExisted = Utils.ensureDb(dbUrl, userName, password); // local method
      if (!dbExisted)
         new SchemaExport(configuration).create(false,true);

does create a new database with the new url (with Utils.ensureDb),
but does not export a schema to it.

This strengthens my suspicions that the configuration has been
carved in stone by .configure and really can't be changed with .setProperty.



> configuration.setProperty("connection.url", newJdbcUrl) fails
> -------------------------------------------------------------
>
>          Key: HHH-1731
>          URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-1731
>      Project: Hibernate3
>         Type: Bug

>   Components: core
>     Versions: 3.1.2
>  Environment: WinXP, Tomcat 5.5, MySQL 5, Hibernate 3.1.2
>     Reporter: Per Lindberg
>  Attachments: HibernateDatabase.java
>
> Original Estimate: 1 hour
>         Remaining: 1 hour
>
> It appears that, after
>    Configuration configuration = new Configuration().configure(cfgFileName);
> but before
>    new SchemaExport(configuration).create(false,true);
>    sessionFactory = configuration.buildSessionFactory()
> the JDBC Connection URL can't be changed with
> configuration.setProperty("connection.url", newJdbcUrl)
> Trying to do so causes configuration.getProperty to return the new value,
> but the SessionFactory gets confused and appears to use the old value.
> I have the impression that configure(cfgFileName) sets the properties
> of the Configuration in some "hard" way, so that later calls to setProperty
> are mostly ignored (except that getProperty returns the new value).
> The attached file attempts to do this, and fails.

-- 
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.jspa
-
For more information on JIRA, see:
   http://www.atlassian.com/software/jira