[Hibernate-JIRA] Created: (HHH-3739) Problem using BTMTransactionManagerLookup with Tomcat
by Helder Sousa (JIRA)
Problem using BTMTransactionManagerLookup with Tomcat
-----------------------------------------------------
Key: HHH-3739
URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-3739
Project: Hibernate Core
Issue Type: Patch
Components: core
Affects Versions: 3.3.1
Environment: Hibernate 3.3.1 GA
Reporter: Helder Sousa
Attachments: BTMTransactionManagerLookup.patch
Hi.
When using Bitronix Transaction Manager with tomcat there is a problem resolving the TransactionManager by JNDI. Please take a look to this thread: http://www.nabble.com/Hibernate-JTATransactionFactory-and-BTMTransactionM...
In 5th post, Ludovic wrote: "The UserTransaction name is java:comp/UserTransaction and when a JNDI lookup happens in Tomcat, the Tomcat provider takes precedence because Tomcat registered a java: namespace handler."
So, when using BTM in Tomcat, the BTM users should configure in BTM Configuration a JNDI name that does not start with java:comp and the BTMTransactionManagerLookup class should read this configuration:
Here is the change to the BTMTransactionManagerLookup class (I attached the patch):
public String getUserTransactionName() {
try {
Class transactionManagerServiceClass = Class.forName("bitronix.tm.TransactionManagerServices");
Method getConfigurationMethod = transactionManagerServiceClass.getMethod("getConfiguration", null);
Object configurationInstance = getConfigurationMethod.invoke(null, null);
Class bitronixConfigurationClass = configurationInstance.getClass();
Method getJndiUserTransactionNameMethod = bitronixConfigurationClass
.getMethod("getJndiUserTransactionName", null);
String configuredJndiUserTransactionName = (String) getJndiUserTransactionNameMethod.invoke(
configurationInstance, null);
if (configuredJndiUserTransactionName != null && configuredJndiUserTransactionName.trim().length() >= 0) {
return configuredJndiUserTransactionName;
}
return "java:comp/UserTransaction";
}
catch (Exception e) {
throw new HibernateException("Could not obtain BTM UserTransactionName", e);
}
}
Can you apply the patch?
Best regards,
Helder Sousa
--
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....
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
14 years, 10 months
[Hibernate-JIRA] Created: (HHH-3968) Error in SchemaUpdate using HSQLDialect with BigInteger or BigDecimal primary keys [similar to HHH.3323]
by Jonathan Mastin (JIRA)
Error in SchemaUpdate using HSQLDialect with BigInteger or BigDecimal primary keys [similar to HHH.3323]
--------------------------------------------------------------------------------------------------------
Key: HHH-3968
URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-3968
Project: Hibernate Core
Issue Type: Bug
Components: core
Affects Versions: 3.3.0.SP1
Environment: HSQLDB: 1.8.0.9
Reporter: Jonathan Mastin
Problem
---------------
When using HSQLDialect, the following code fails during schema creation:
@Entity
public class Test {
@Id @GeneratedValue(strategy = GenerationType.AUTO)
private BigInteger id;
}
Log output:
----------------
ERROR org.hibernate.tool.hbm2ddl.SchemaUpdate - Unsuccessful: create table Test (id numeric generated by default as identity (start with 1), primary key (id))
ERROR org.hibernate.tool.hbm2ddl.SchemaUpdate - Wrong data type: id in statement [create table Test (id numeric generated by default as identity (start with 1)]
Expected
---------------------------------
The column type is being set as "numeric", but it needs to be set as "integer" or "bigint" for HSQL to be able to parse.
>From the HSQL manual:
"The supported form is(<colname> INTEGER GENERATED BY DEFAULT AS IDENTITY(START WITH n, [INCREMENT BY m])PRIMARY KEY, ...). Support has also been added for BIGINT identity columns. As a result, an IDENTITY column is simply an INTEGER or BIGINT column ..."
--
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....
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
14 years, 11 months
[Hibernate-JIRA] Created: (HHH-2862) Collection is not associated with any session exception when doing an eager fetch on a non-unique collection.
by Paul Andrews (JIRA)
Collection is not associated with any session exception when doing an eager fetch on a non-unique collection.
-------------------------------------------------------------------------------------------------------------
Key: HHH-2862
URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-2862
Project: Hibernate3
Issue Type: Bug
Environment: Hibernate 3.1.3 - Hibernate 3.2.5, HSQLDB, Java5
Reporter: Paul Andrews
It is basically caused by having an eager collection where the key of the collection is not unique in the results.
The code works as follows in CollectionType.getCollection():
....
persistenceContext.addUninitializedCollection( persister, collection, key );
// some collections are not lazy:
if ( initializeImmediately( entityMode ) ) {
session.initializeCollection( collection, false );
}
else if ( !persister.isLazy() ) {
persistenceContext.addNonLazyCollection( collection );
}
if ( hasHolder( entityMode ) ) {
session.getPersistenceContext().addCollectionHolder( collection );
}
if persistenceContext.addUninitializedCollection() detects that the collection with the given key has already been added it clears the session on the old instance of the collection (sets it to null). However, that collection has already been added to the persistence context by an earlier call to this method. So later when StatefulPersistenceContext.initializeNonLazyCollections() is called it iterates through all of the collections in the persistence context (including those which have had their session set to null by addUninitializedCollection()), calling forceInitialization() which throws a 'collection is not associated with any session' exception.
--
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....
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
14 years, 11 months