[Hibernate-JIRA] Commented: (HHH-1786) JTASessionContext.CleanupSynch does not remove sessions from currentSessionMap
by Steve Ebersole (JIRA)
[ http://opensource.atlassian.com/projects/hibernate/browse/HHH-1786?page=c... ]
Steve Ebersole commented on HHH-1786:
-------------------------------------
Gary, thanks for reporting and looking into this. However, pasting the diff directly into a comment here makes it really unreadable.
It looks like I just forgot to use the "transaction identifier" explicitly when:
1) getting from the map
2) removing from map (in CleanupSynch)
(see the patch or fisheye logs on the linked case).
> JTASessionContext.CleanupSynch does not remove sessions from currentSessionMap
> ------------------------------------------------------------------------------
>
> Key: HHH-1786
> URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-1786
> Project: Hibernate3
> Issue Type: Improvement
> Affects Versions: 3.1.2
> Environment: IBM WebSphere 6.0.2.7, Hibernate CVS snapshot from 2006-02-24
> Reporter: Tomi Szabo
> Assignee: Steve Ebersole
> Fix For: 3.3.0.CR2
>
> Attachments: JTASessionContext.java, screenshot-1.jpg, screenshot-2.jpg, WebSphereExtendedJTATransactionLookup.java, WebSphereExtendedJTATransactionLookup.patch.txt
>
>
> We are using JTASessionContext, CMTTransaction and WebSphereExtendedJTATransactionLookup. We have experienced some memmory leak problems and after closer inspection we have found that Hibernate sessions are not removed from currentSessionMap inside JTASessionContext.
> Method JTASessionContext.CleanupSynch.afterCompletion() is called as expected but code "context.currentSessionMap.remove( txn );" does not remove session from Map because of key's hashcode has changed. This is due to fact that com.ibm.websphere.jtaextensions.ExtendedJTATransaction.hashCode is actually ID of underlaying transaction. But if it comes to the afterCompletion method in CleanupSynch the underlaying transaction is already closed. Closed transaction has ID 0 (default value) and it is different from ID under which the Hibernate session was previously inserted into Map.
> Possible patch is in attachements.
--
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
16 years, 4 months
[Hibernate-JIRA] Created: (HHH-3470) Polymorphic query doesn't return all objects it should return
by Jens Laufer (JIRA)
Polymorphic query doesn't return all objects it should return
-------------------------------------------------------------
Key: HHH-3470
URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-3470
Project: Hibernate3
Issue Type: Bug
Affects Versions: 3.2.6
Environment: Window Vista, Maven 2.0.9, Eclipse Ganymed, Hibernate 3.2.6.ga, Sping 2.5.5, hsqldb
Reporter: Jens Laufer
Attachments: hibernate-polymorphic-query-test.zip
I have got an abstract class (Address) with three implementations (PostalAddress, FaxNumber, PhoneNumber).
The FaxNumber and the PhoneNumber have a property number. PostalAddress has some more properties (name, postalCode, city, addressLine).
In the hibernate mapping I am having a inheritance mapping with joined-subclass. In case I am persisting three objects (a PostalAddress, a PhoneNumber and a FaxNumber) and I build a query that has a wildcard search on all properties of the mentioned objects I am just getting two objects backs. PostalAddress
is returned plus either PhoneNumber or FaxNumber. Which second object is returned depends on what is defined first in the mapping file. If define Phonenumber first, the PhoneNumber is returned but not the FaxNumber.
The query is: FROM Address WHERE number LIKE :query OR postalCode LIKE :query OR name LIKE :query OR city LIKE :query OR addressLine LIKE :query
I attached a litte test project with a unit test, that proofs this. The project can be imported into eclipse or the test can be run during the maven2 built.
--
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
16 years, 4 months
[Hibernate-JIRA] Created: (ANN-773) AttributeOverride ignores column name for "xRay" property (or apparently any property with a single initial lowercase property)
by Tobin Edwards (JIRA)
AttributeOverride ignores column name for "xRay" property (or apparently any property with a single initial lowercase property)
-------------------------------------------------------------------------------------------------------------------------------
Key: ANN-773
URL: http://opensource.atlassian.com/projects/hibernate/browse/ANN-773
Project: Hibernate Annotations
Issue Type: Bug
Affects Versions: 3.3.0.ga
Environment: hibernate3, hsqldb 1.8.0.9
Reporter: Tobin Edwards
Hibernate generates these column names in the database (note that XRAY column should be VISION_XRAY):
XRAY BOOLEAN,
VISION_BLIND BOOLEAN,
VISION_LASER BOOLEAN
when using the following classes:
@Embeddable
public class Vision
{
public Vision()
{
}
private Boolean blind;
public Boolean getBlind() { return this.blind; }
public void setBlind(Boolean value) { this.blind = value; }
private Boolean xRay;
public Boolean getXRay() { return this.xRay; }
public void setXRay(Boolean value) { this.xRay = value; }
private Boolean laser;
public Boolean getLaser() { return this.laser; }
public void setLaser(Boolean value) { this.laser = value; }
}
@Entity
public class SuperHero
{
private Long _id;
@Id
@GeneratedValue
public Long get_id() { return this._id; }
public void set_id(Long id) { this._id = id; }
private Vision vision;
@Embedded
@AttributeOverrides (
{
@AttributeOverride(name="blind", column=@Column(name="vision_blind") ),
@AttributeOverride(name="xRay", column=@Column(name="vision_xRay") ),
@AttributeOverride(name="laser", column=@Column(name="vision_laser") )
} )
public Vision getVision() { return this.vision; }
public void setVision(Vision value) { this.vision = value; }
}
--
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
16 years, 4 months
[Hibernate-JIRA] Created: (HHH-3466) Hibernate cannot be built with JDK 1.4, nor with JDK 1.6
by Andra Nedelcovici (JIRA)
Hibernate cannot be built with JDK 1.4, nor with JDK 1.6
--------------------------------------------------------
Key: HHH-3466
URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-3466
Project: Hibernate3
Issue Type: Bug
Components: build
Affects Versions: 3.3.0.SP1
Reporter: Andra Nedelcovici
Priority: Critical
Despite the fact that Hibernate officially requires JRE 1.4 only, it cannot be built from sources using JDK 1.4.
There is a restriction enforced in a Maven configuration file upon the building JDK version, namely at least 1.5 is required. Removing this restriction yields some JUnit test errors for JBoss cache.
Conversely, Hibernate cannot be built with JDK 1.6 since JDBC 4.0 adds some new methods that Hibernate is not aware of and the compilation fails.
The solution is:
- not to build JBoss(2) cache when the building JDK is 1.4 (already missing Ant ?)
- to account for the new methods introduced in JDBC 4.0 (even if they are not needed they must be implemented)
--
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
16 years, 4 months
[Hibernate-JIRA] Created: (HHH-2586) Hibernate Serializable classes do not declare serialVersionUID
by Manuel Dominguez Sarmiento (JIRA)
Hibernate Serializable classes do not declare serialVersionUID
--------------------------------------------------------------
Key: HHH-2586
URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-2586
Project: Hibernate3
Issue Type: Bug
Components: core
Affects Versions: 3.2.3, 3.2.2, 3.2.1, 3.2.0.ga, 3.2.0.cr5, 3.2.0.cr4, 3.2.0.cr3, 3.2.0.cr2, 3.2.0 cr1, 3.1.3, 3.2.0.alpha2, 3.2.0.alpha1, 3.1.2, 3.1.1, 3.1, 3.1 rc3, 3.1 rc2, 3.1 rc 1, 3.1 beta 2, 3.1 beta 1, 3.0.5, 3.0.4, 3.0.3, 3.0.2, 3.0.1, 3.0 final, 3.0 rc 1, 3.0 beta 4, 3.0 beta 3, 3.0 beta 2, 3.0 beta 1, 3.0 alpha
Environment: Not specific to any database, platform or Hibernate version.
Reporter: Manuel Dominguez Sarmiento
None of the Serializable classes in Hibernate declare serialVersionUID (see http://www.hibernate.org/hib_docs/v3/api/serialized-form.html#org.hiberna...).
This is recommended practice for ALL classes that implement the Serializable interface (see Joshua Bloch's Effective Java - Item #54). Adding these fields is trivial and takes little effort, but is a great enhancement if you are serializing Hibernate classes.
For instance, we upgraded from Hibernate 3.2.2 to 3.2.3 in our production servers. We serialize process state (which sometimes includes references to Hibernate-managed entities) every 30 seconds or so and on shutdown, so in the event of failures or re-deployment, the processes can continue where they left off. We had a huge surprise when deserialization failed completely because AbstractPersistentCollection had slightly changed between the 3.2.2 and 3.2.3 releases, and this caused the automatically-generated default serialVersionUID to change, even though the changes in the serialized form are compatible as far as we can tell.
--
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
16 years, 4 months
[Hibernate-JIRA] Created: (HHH-3379) Dialect support for SQL comments
by Daniel Bell (JIRA)
Dialect support for SQL comments
--------------------------------
Key: HHH-3379
URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-3379
Project: Hibernate3
Issue Type: Patch
Affects Versions: 3.2.6
Environment: Hibernate 3.2.6.ga, Informix 7.31
Reporter: Daniel Bell
Attachments: hibernate.dialect.patch
I have recently tried turning on SQL comments in hibernate 3.2.6.ga.
However, I found that our database (informix 7.31) did not support SQL
where the comment was at the start of the comment. Instead, the comment
needed to be after the SQL. For example:
/* not accepted by informix 7.31*/ select * from systables;
select * from systables /* accepted by informix 7.31*/
Because of this, I have added a method to the Dialect for adding comments:
/**
* Add a comment to the SQL string.
*
* @param sql StringBuffer holding the SQL.
* @param comment Comment to add to the SQL. May be null.
*/
public void addCommentToSql(StringBuffer sql, String comment) {
if (StringHelper.isNotEmpty(comment))
sql.insert(0, "/* " + comment + " */ ");
}
Thus, the default implementation provides the same functionality as
before. However, derived Dialects may override this method to add the
comment in a different location.
It is also possible to add additional comments in the derived Dialect.
In our case, we also add the Java thread ID.
--
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
16 years, 4 months