Menu
▾
▴
hibernate-issues — Hibernate JIRA Notifications
You can subscribe to this list here.
| 2003 |
Jan
|
Feb
|
Mar
|
Apr
|
May
(32) |
Jun
(175) |
Jul
(209) |
Aug
(302) |
Sep
(287) |
Oct
(339) |
Nov
(314) |
Dec
(329) |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2004 |
Jan
(479) |
Feb
(389) |
Mar
(599) |
Apr
(307) |
May
(390) |
Jun
(300) |
Jul
(410) |
Aug
(458) |
Sep
(299) |
Oct
(315) |
Nov
(363) |
Dec
(529) |
| 2005 |
Jan
(568) |
Feb
(434) |
Mar
(1004) |
Apr
(823) |
May
(767) |
Jun
(763) |
Jul
(854) |
Aug
(862) |
Sep
(560) |
Oct
(853) |
Nov
(763) |
Dec
(731) |
| 2006 |
Jan
(776) |
Feb
(608) |
Mar
(657) |
Apr
(424) |
May
(559) |
Jun
(440) |
Jul
(448) |
Aug
(58) |
Sep
|
Oct
(17) |
Nov
(16) |
Dec
(8) |
| 2007 |
Jan
(1) |
Feb
(8) |
Mar
(2) |
Apr
(5) |
May
(3) |
Jun
(3) |
Jul
(3) |
Aug
(16) |
Sep
(10) |
Oct
(4) |
Nov
(4) |
Dec
(4) |
| 2008 |
Jan
(8) |
Feb
(1) |
Mar
(1) |
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
(1) |
Oct
|
Nov
|
Dec
|
| 2009 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
(1) |
Oct
|
Nov
|
Dec
|
|
From: <leg...@at...> - 2003-09-30 15:30:20
|
Message: A new issue has been created in JIRA. --------------------------------------------------------------------- View the issue: http://opensource.atlassian.com/projects/hibernate/secure/ViewIssue.jspa?key=HB-371 Here is an overview of the issue: --------------------------------------------------------------------- Key: HB-371 Summary: Commit in SchemaUpdate Type: Bug Status: Unassigned Priority: Major Project: Hibernate2 Components: toolset Versions: 2.1 beta 3 Assignee: Reporter: xfgdf Created: Tue, 30 Sep 2003 10:29 AM Updated: Tue, 30 Sep 2003 10:29 AM Environment: JBoss 3.2 EJB stateless with container managed transaction. Oracle 8i with JdbcOdbc sun driver. Description: There is a call to commit() in Schema Update that throws an : java.sql.SQLException: You cannot commit with autocommit set! at org.jboss.resource.adapter.jdbc.BaseWrapperManagedConnection.jdbcCommit(BaseWrapperManagedConnection.java:494) at org.jboss.resource.adapter.jdbc.WrappedConnection.commit(WrappedConnection.java:465) at net.sf.hibernate.tool.hbm2ddl.SchemaUpdate.execute(SchemaUpdate.java:99) If, for some reasons, this commit is necessary to access Metadata, Hibernate should call setAutocommit(false) before. Thanks... Adrien --------------------------------------------------------------------- JIRA INFORMATION: 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 If you want more information on JIRA, or have a bug to report see: http://www.atlassian.com/software/jira |
|
From: <leg...@at...> - 2003-09-30 12:20:20
|
Message:
The following issue has been closed.
Resolver: Gavin King
Date: Tue, 30 Sep 2003 7:19 AM
I think this is addressed really nicely by the new query by Example API.
---------------------------------------------------------------------
View the issue:
http://opensource.atlassian.com/projects/hibernate/secure/ViewIssue.jspa?key=HB-61
Here is an overview of the issue:
---------------------------------------------------------------------
Key: HB-61
Summary: Query by Criteria - Proposed Enhancements
Type: Improvement
Status: Closed
Priority: Major
Resolution: FIXED
Project: Hibernate2
Components:
core
Fix Fors:
2.1 beta 4
Assignee:
Reporter: Matt Raible
Created: Tue, 6 May 2003 11:49 AM
Updated: Tue, 30 Sep 2003 7:19 AM
Description:
I documented improvements I'd like to see in the Query by Criteria feature. These improvements can be found at:
http://static.raibledesigns.com/hibernate-query.html
---------------------------------------------------------------------
JIRA INFORMATION:
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
If you want more information on JIRA, or have a bug to report see:
http://www.atlassian.com/software/jira
|
|
From: <leg...@at...> - 2003-09-30 00:40:20
|
The following comment has been added to this issue:
Author: John Kristian
Created: Mon, 29 Sep 2003 7:39 PM
Body:
> The create tables script ... uses "insert ... select"s from nonexistent tables!
Please try test3.zip instead, if you have Microsoft SQL Server. The createTables.sql in test2.zip contained references to tables it didn't create (for which I apologized). I corrected this problem in subsequent attachments, although they remain specific to SQL Server.
> Test data should be created via Hibernate itself.
OK; I'll do that, and attach the portable test data here when I've done (tomorrow, probably).
---------------------------------------------------------------------
View the issue:
http://opensource.atlassian.com/projects/hibernate/secure/ViewIssue.jspa?key=HB-367
Here is an overview of the issue:
---------------------------------------------------------------------
Key: HB-367
Summary: JCSCache.put java.lang.Error: update: last is null!
Type: Bug
Status: Unassigned
Priority: Major
Project: Hibernate2
Versions:
2.1 beta 3
Assignee:
Reporter: John Kristian
Created: Fri, 26 Sep 2003 4:15 PM
Updated: Mon, 29 Sep 2003 1:28 PM
Environment: Windows XP, Microsoft SQL Server
Description:
With Hibernate `cvs checkout -r v21branch` (but not 2.0.2), the following errors occur.
14:05:11,046 ERROR [org.apache.jcs.engine.memory.lru.LRUMemoryCache] verifycache: map does NOT contain key, what the HECK!
14:05:11,046 ERROR [com.docent.lms.entities.tests.hibernate.Scan] testScan failed
java.lang.Error: update: last is null!
at org.apache.jcs.engine.memory.lru.LRUMemoryCache.update(LRUMemoryCache.java:140)
at org.apache.jcs.engine.control.CompositeCache.update(CompositeCache.java:241)
at org.apache.jcs.engine.control.CompositeCache.update(CompositeCache.java:200)
at org.apache.jcs.access.CacheAccess.put(CacheAccess.java:311)
at org.apache.jcs.access.CacheAccess.put(CacheAccess.java:279)
at net.sf.hibernate.cache.JCSCache.put(JCSCache.java:34)
at net.sf.hibernate.cache.ReadWriteCache.put(ReadWriteCache.java:86)
at net.sf.hibernate.impl.SessionImpl.initializeEntity(SessionImpl.java:2191)
at net.sf.hibernate.loader.Loader.doResultSet(Loader.java:216)
at net.sf.hibernate.loader.Loader.doFind(Loader.java:111)
at net.sf.hibernate.loader.Loader.loadEntity(Loader.java:664)
at net.sf.hibernate.loader.Loader.loadEntity(Loader.java:679)
at net.sf.hibernate.loader.EntityLoader.load(EntityLoader.java:52)
at net.sf.hibernate.loader.EntityLoader.load(EntityLoader.java:44)
at net.sf.hibernate.persister.EntityPersister.load(EntityPersister.java:424)
at net.sf.hibernate.impl.SessionImpl.doLoad(SessionImpl.java:2115)
at net.sf.hibernate.impl.SessionImpl.doLoadByClass(SessionImpl.java:1977)
at net.sf.hibernate.impl.SessionImpl.internalLoad(SessionImpl.java:1936)
at net.sf.hibernate.type.ManyToOneType.resolveIdentifier(ManyToOneType.java:76)
at net.sf.hibernate.type.EntityType.assemble(EntityType.java:113)
at net.sf.hibernate.collection.Set.<init>(Set.java:94)
at net.sf.hibernate.type.SetType.assembleCachedCollection(SetType.java:36)
at net.sf.hibernate.collection.CollectionPersister.getCachedCollection(CollectionPersister.java:371)
at net.sf.hibernate.type.PersistentCollectionType.getCollection(PersistentCollectionType.java:67)
at net.sf.hibernate.type.PersistentCollectionType.resolveIdentifier(PersistentCollectionType.java:184)
at net.sf.hibernate.type.PersistentCollectionType.assemble(PersistentCollectionType.java:134)
at net.sf.hibernate.impl.CacheEntry.assemble(CacheEntry.java:54)
at net.sf.hibernate.impl.CacheEntry.assemble(CacheEntry.java:46)
at net.sf.hibernate.impl.SessionImpl.doLoad(SessionImpl.java:2100)
at net.sf.hibernate.impl.SessionImpl.doLoadByClass(SessionImpl.java:1977)
at net.sf.hibernate.impl.SessionImpl.internalLoad(SessionImpl.java:1936)
at net.sf.hibernate.type.ManyToOneType.resolveIdentifier(ManyToOneType.java:76)
at net.sf.hibernate.type.EntityType.nullSafeGet(EntityType.java:129)
at net.sf.hibernate.impl.IteratorImpl.postNext(IteratorImpl.java:67)
at net.sf.hibernate.impl.IteratorImpl.next(IteratorImpl.java:87)
at com.docent.lms.entities.tests.hibernate.Scan.scan(Scan.java:59)
---------------------------------------------------------------------
JIRA INFORMATION:
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
If you want more information on JIRA, or have a bug to report see:
http://www.atlassian.com/software/jira
|
|
From: <leg...@at...> - 2003-09-29 23:43:19
|
The following comment has been added to this issue:
Author: Gavin King
Created: Mon, 29 Sep 2003 6:43 PM
Body:
The create tables script you gave is completely useless, because it uses "insert ... select"s from nonexistent tables! I don't think that wrapping this in a utility is going to help much.
The correct way to provide this stuff is to use "new SchemaExport(...).create()" to set up the tables, which ensures that I can run it on any platform. Test data should be created via Hibernate itself.
---------------------------------------------------------------------
View the issue:
http://opensource.atlassian.com/projects/hibernate/secure/ViewIssue.jspa?key=HB-367
Here is an overview of the issue:
---------------------------------------------------------------------
Key: HB-367
Summary: JCSCache.put java.lang.Error: update: last is null!
Type: Bug
Status: Unassigned
Priority: Major
Project: Hibernate2
Versions:
2.1 beta 3
Assignee:
Reporter: John Kristian
Created: Fri, 26 Sep 2003 4:15 PM
Updated: Mon, 29 Sep 2003 1:28 PM
Environment: Windows XP, Microsoft SQL Server
Description:
With Hibernate `cvs checkout -r v21branch` (but not 2.0.2), the following errors occur.
14:05:11,046 ERROR [org.apache.jcs.engine.memory.lru.LRUMemoryCache] verifycache: map does NOT contain key, what the HECK!
14:05:11,046 ERROR [com.docent.lms.entities.tests.hibernate.Scan] testScan failed
java.lang.Error: update: last is null!
at org.apache.jcs.engine.memory.lru.LRUMemoryCache.update(LRUMemoryCache.java:140)
at org.apache.jcs.engine.control.CompositeCache.update(CompositeCache.java:241)
at org.apache.jcs.engine.control.CompositeCache.update(CompositeCache.java:200)
at org.apache.jcs.access.CacheAccess.put(CacheAccess.java:311)
at org.apache.jcs.access.CacheAccess.put(CacheAccess.java:279)
at net.sf.hibernate.cache.JCSCache.put(JCSCache.java:34)
at net.sf.hibernate.cache.ReadWriteCache.put(ReadWriteCache.java:86)
at net.sf.hibernate.impl.SessionImpl.initializeEntity(SessionImpl.java:2191)
at net.sf.hibernate.loader.Loader.doResultSet(Loader.java:216)
at net.sf.hibernate.loader.Loader.doFind(Loader.java:111)
at net.sf.hibernate.loader.Loader.loadEntity(Loader.java:664)
at net.sf.hibernate.loader.Loader.loadEntity(Loader.java:679)
at net.sf.hibernate.loader.EntityLoader.load(EntityLoader.java:52)
at net.sf.hibernate.loader.EntityLoader.load(EntityLoader.java:44)
at net.sf.hibernate.persister.EntityPersister.load(EntityPersister.java:424)
at net.sf.hibernate.impl.SessionImpl.doLoad(SessionImpl.java:2115)
at net.sf.hibernate.impl.SessionImpl.doLoadByClass(SessionImpl.java:1977)
at net.sf.hibernate.impl.SessionImpl.internalLoad(SessionImpl.java:1936)
at net.sf.hibernate.type.ManyToOneType.resolveIdentifier(ManyToOneType.java:76)
at net.sf.hibernate.type.EntityType.assemble(EntityType.java:113)
at net.sf.hibernate.collection.Set.<init>(Set.java:94)
at net.sf.hibernate.type.SetType.assembleCachedCollection(SetType.java:36)
at net.sf.hibernate.collection.CollectionPersister.getCachedCollection(CollectionPersister.java:371)
at net.sf.hibernate.type.PersistentCollectionType.getCollection(PersistentCollectionType.java:67)
at net.sf.hibernate.type.PersistentCollectionType.resolveIdentifier(PersistentCollectionType.java:184)
at net.sf.hibernate.type.PersistentCollectionType.assemble(PersistentCollectionType.java:134)
at net.sf.hibernate.impl.CacheEntry.assemble(CacheEntry.java:54)
at net.sf.hibernate.impl.CacheEntry.assemble(CacheEntry.java:46)
at net.sf.hibernate.impl.SessionImpl.doLoad(SessionImpl.java:2100)
at net.sf.hibernate.impl.SessionImpl.doLoadByClass(SessionImpl.java:1977)
at net.sf.hibernate.impl.SessionImpl.internalLoad(SessionImpl.java:1936)
at net.sf.hibernate.type.ManyToOneType.resolveIdentifier(ManyToOneType.java:76)
at net.sf.hibernate.type.EntityType.nullSafeGet(EntityType.java:129)
at net.sf.hibernate.impl.IteratorImpl.postNext(IteratorImpl.java:67)
at net.sf.hibernate.impl.IteratorImpl.next(IteratorImpl.java:87)
at com.docent.lms.entities.tests.hibernate.Scan.scan(Scan.java:59)
---------------------------------------------------------------------
JIRA INFORMATION:
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
If you want more information on JIRA, or have a bug to report see:
http://www.atlassian.com/software/jira
|
|
From: <leg...@at...> - 2003-09-29 21:27:20
|
Message:
The following issue has been closed.
Resolver: Gavin King
Date: Mon, 29 Sep 2003 4:26 PM
This is correct and essential functionality. Hibernate guarantess transaction-scoped identity.
---------------------------------------------------------------------
View the issue:
http://opensource.atlassian.com/projects/hibernate/secure/ViewIssue.jspa?key=HB-370
Here is an overview of the issue:
---------------------------------------------------------------------
Key: HB-370
Summary: load(Class, Serializable) behaves differently than load(Object, Serializable)
Type: Bug
Status: Closed
Priority: Minor
Resolution: REJECTED
Project: Hibernate2
Components:
core
Versions:
2.0.3
Assignee:
Reporter: Bernard Ligny
Created: Mon, 29 Sep 2003 9:20 AM
Updated: Mon, 29 Sep 2003 4:26 PM
Environment: Win Xp, JDK 1.4
Description:
I noticed two different behaviours depending on the fact that I am using the session.load() with an Object or a Class as first parameter.
The problem appears when trying to load more than once a same persistent instance in the same session:
Example 1: crash
=========
tx = session.beginTransaction();
Object obj1 = new MyObjectClass();
session.load(obj1, new Long(123));
Object obj2 = new MyObjectClass();
session.load(obj2, new Long(123));
...
=> throws an Hibernate Exception for 2nd load
("already an object with that id in session")
Example 2 : works perfectly !
=========
(the same code but using the other load signature)
tx = session.beginTransaction();
Object obj1 = session.load(MyObjectClass, new Long(123));
Object obj2 = session.load(MyObjectClass, new Long(123));
...
***
The annoying point is that the not-working example is the one in the "Root Persistent Class" design pattern:
public void refresh() throws HibernateException, SQLException {
HibernateSession.currentSession().load(this, _id);
}
---------------------------------------------------------------------
JIRA INFORMATION:
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
If you want more information on JIRA, or have a bug to report see:
http://www.atlassian.com/software/jira
|
|
From: <leg...@at...> - 2003-09-29 18:30:10
|
The following issue has been updated:
Updater: John Kristian (mailto:jkr...@do...)
Date: Mon, 29 Sep 2003 1:28 PM
Comment:
test3.zip (attached) includes a utility program CreateTables.java that creates database tables and data sufficient to reproduce this problem. (It reads the SQL statements from createTables.sql.) If this is still 'useless', please let me know what would be useful. I'm eager to help you reproduce this problem, but I don't have a clear idea what I can do to help.
test3.zip also includes a version of Scan.java that checks for 'lost' members of the Role.associations set. It finds several:
11:14:43,859 ERROR [com.docent.lms.entities.tests.hibernate.Scan] !Role#8...@10...ntains(RolePermissionAssociation#{Role#8@1045, Permission#48@1046}@1047)
11:14:43,875 ERROR [com.docent.lms.entities.tests.hibernate.Scan] !Role#7...@10...ntains(RolePermissionAssociation#{Role#7@1049, Permission#48@1046}@1050)
11:14:49,281 ERROR [com.docent.lms.entities.tests.hibernate.Scan] !Role#6...@10...ntains(RolePermissionAssociation#{Role#6@1058, Permission#102@1059}@1060)
... which suggests that Hibernate collections are also affected by this problem.
Changes:
Attachment changed to test3.zip
---------------------------------------------------------------------
For a full history of the issue, see:
http://opensource.atlassian.com/projects/hibernate/secure/ViewIssue.jspa?key=HB-367&page=history
---------------------------------------------------------------------
View the issue:
http://opensource.atlassian.com/projects/hibernate/secure/ViewIssue.jspa?key=HB-367
Here is an overview of the issue:
---------------------------------------------------------------------
Key: HB-367
Summary: JCSCache.put java.lang.Error: update: last is null!
Type: Bug
Status: Unassigned
Priority: Major
Project: Hibernate2
Versions:
2.1 beta 3
Assignee:
Reporter: John Kristian
Created: Fri, 26 Sep 2003 4:15 PM
Updated: Mon, 29 Sep 2003 1:28 PM
Environment: Windows XP, Microsoft SQL Server
Description:
With Hibernate `cvs checkout -r v21branch` (but not 2.0.2), the following errors occur.
14:05:11,046 ERROR [org.apache.jcs.engine.memory.lru.LRUMemoryCache] verifycache: map does NOT contain key, what the HECK!
14:05:11,046 ERROR [com.docent.lms.entities.tests.hibernate.Scan] testScan failed
java.lang.Error: update: last is null!
at org.apache.jcs.engine.memory.lru.LRUMemoryCache.update(LRUMemoryCache.java:140)
at org.apache.jcs.engine.control.CompositeCache.update(CompositeCache.java:241)
at org.apache.jcs.engine.control.CompositeCache.update(CompositeCache.java:200)
at org.apache.jcs.access.CacheAccess.put(CacheAccess.java:311)
at org.apache.jcs.access.CacheAccess.put(CacheAccess.java:279)
at net.sf.hibernate.cache.JCSCache.put(JCSCache.java:34)
at net.sf.hibernate.cache.ReadWriteCache.put(ReadWriteCache.java:86)
at net.sf.hibernate.impl.SessionImpl.initializeEntity(SessionImpl.java:2191)
at net.sf.hibernate.loader.Loader.doResultSet(Loader.java:216)
at net.sf.hibernate.loader.Loader.doFind(Loader.java:111)
at net.sf.hibernate.loader.Loader.loadEntity(Loader.java:664)
at net.sf.hibernate.loader.Loader.loadEntity(Loader.java:679)
at net.sf.hibernate.loader.EntityLoader.load(EntityLoader.java:52)
at net.sf.hibernate.loader.EntityLoader.load(EntityLoader.java:44)
at net.sf.hibernate.persister.EntityPersister.load(EntityPersister.java:424)
at net.sf.hibernate.impl.SessionImpl.doLoad(SessionImpl.java:2115)
at net.sf.hibernate.impl.SessionImpl.doLoadByClass(SessionImpl.java:1977)
at net.sf.hibernate.impl.SessionImpl.internalLoad(SessionImpl.java:1936)
at net.sf.hibernate.type.ManyToOneType.resolveIdentifier(ManyToOneType.java:76)
at net.sf.hibernate.type.EntityType.assemble(EntityType.java:113)
at net.sf.hibernate.collection.Set.<init>(Set.java:94)
at net.sf.hibernate.type.SetType.assembleCachedCollection(SetType.java:36)
at net.sf.hibernate.collection.CollectionPersister.getCachedCollection(CollectionPersister.java:371)
at net.sf.hibernate.type.PersistentCollectionType.getCollection(PersistentCollectionType.java:67)
at net.sf.hibernate.type.PersistentCollectionType.resolveIdentifier(PersistentCollectionType.java:184)
at net.sf.hibernate.type.PersistentCollectionType.assemble(PersistentCollectionType.java:134)
at net.sf.hibernate.impl.CacheEntry.assemble(CacheEntry.java:54)
at net.sf.hibernate.impl.CacheEntry.assemble(CacheEntry.java:46)
at net.sf.hibernate.impl.SessionImpl.doLoad(SessionImpl.java:2100)
at net.sf.hibernate.impl.SessionImpl.doLoadByClass(SessionImpl.java:1977)
at net.sf.hibernate.impl.SessionImpl.internalLoad(SessionImpl.java:1936)
at net.sf.hibernate.type.ManyToOneType.resolveIdentifier(ManyToOneType.java:76)
at net.sf.hibernate.type.EntityType.nullSafeGet(EntityType.java:129)
at net.sf.hibernate.impl.IteratorImpl.postNext(IteratorImpl.java:67)
at net.sf.hibernate.impl.IteratorImpl.next(IteratorImpl.java:87)
at com.docent.lms.entities.tests.hibernate.Scan.scan(Scan.java:59)
---------------------------------------------------------------------
JIRA INFORMATION:
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
If you want more information on JIRA, or have a bug to report see:
http://www.atlassian.com/software/jira
|
|
From: <leg...@at...> - 2003-09-29 14:22:41
|
Message: A new issue has been created in JIRA. --------------------------------------------------------------------- View the issue: http://opensource.atlassian.com/projects/hibernate/secure/ViewIssue.jspa?key=HB-370 Here is an overview of the issue: --------------------------------------------------------------------- Key: HB-370 Summary: load(Class, Serializable) behaves differently than load(Object, Serializable) Type: Bug Status: Unassigned Priority: Minor Project: Hibernate2 Components: core Versions: 2.0.3 Assignee: Reporter: Bernard Ligny Created: Mon, 29 Sep 2003 9:20 AM Updated: Mon, 29 Sep 2003 9:20 AM Environment: Win Xp, JDK 1.4 Description: I noticed two different behaviours depending on the fact that I am using the session.load() with an Object or a Class as first parameter. The problem appears when trying to load more than once a same persistent instance in the same session: Example 1: crash ========= tx = session.beginTransaction(); Object obj1 = new MyObjectClass(); session.load(obj1, new Long(123)); Object obj2 = new MyObjectClass(); session.load(obj2, new Long(123)); ... => throws an Hibernate Exception for 2nd load ("already an object with that id in session") Example 2 : works perfectly ! ========= (the same code but using the other load signature) tx = session.beginTransaction(); Object obj1 = session.load(MyObjectClass, new Long(123)); Object obj2 = session.load(MyObjectClass, new Long(123)); ... *** The annoying point is that the not-working example is the one in the "Root Persistent Class" design pattern: public void refresh() throws HibernateException, SQLException { HibernateSession.currentSession().load(this, _id); } --------------------------------------------------------------------- JIRA INFORMATION: 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 If you want more information on JIRA, or have a bug to report see: http://www.atlassian.com/software/jira |
|
From: <leg...@at...> - 2003-09-29 11:54:24
|
The following issue has been updated:
Updater: Thorsten Ehlers (mailto:tho...@fr...)
Date: Mon, 29 Sep 2003 6:12 AM
Changes:
Attachment changed to dbcp-full-feature-support-2.0.3-patch.diff
---------------------------------------------------------------------
For a full history of the issue, see:
http://opensource.atlassian.com/projects/hibernate/secure/ViewIssue.jspa?key=HB-369&page=history
---------------------------------------------------------------------
View the issue:
http://opensource.atlassian.com/projects/hibernate/secure/ViewIssue.jspa?key=HB-369
Here is an overview of the issue:
---------------------------------------------------------------------
Key: HB-369
Summary: Full feature support for connection pool DBCP in Hibernate 2.0.3
Type: Patch
Status: Unassigned
Priority: Major
Project: Hibernate2
Components:
core
Versions:
2.0.3
Assignee:
Reporter: Thorsten Ehlers
Created: Mon, 29 Sep 2003 6:11 AM
Updated: Mon, 29 Sep 2003 6:12 AM
Description:
The attached patch extends Hibernate 2.0.3 to support all features of the Apache DBCP.
I'm well aware that similiar patches (HBI-4, HB-51) have already been rejected, but unfortunately we need those
extra-features in our project. In our setup the provider has set up a firewall between database and servlet-container that "kills" idle connections. Unfortunately it does a very bad job of it, so that we end up with a lot of connections that are not closed but are also not open anymore... In the end the whole system was hanging after a night of inactivity. By using the additional DBCP properties we were able to solve that problem.
I would really appreciate if you add that patch to the system, because I don't like the idea of adding it manually to every new release of Hibernate and I think that other people might encounter similiar problems. Above all it's not a big change at all. Most people won't notice any difference, because we use the normal defaults, if no properties are supplied by the user.
---------------------------------------------------------------------
JIRA INFORMATION:
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
If you want more information on JIRA, or have a bug to report see:
http://www.atlassian.com/software/jira
|
|
From: <leg...@at...> - 2003-09-29 11:54:23
|
Message: A new issue has been created in JIRA. --------------------------------------------------------------------- View the issue: http://opensource.atlassian.com/projects/hibernate/secure/ViewIssue.jspa?key=HB-369 Here is an overview of the issue: --------------------------------------------------------------------- Key: HB-369 Summary: Full feature support for connection pool DBCP in Hibernate 2.0.3 Type: Patch Status: Unassigned Priority: Major Project: Hibernate2 Components: core Versions: 2.0.3 Assignee: Reporter: Thorsten Ehlers Created: Mon, 29 Sep 2003 6:11 AM Updated: Mon, 29 Sep 2003 6:11 AM Description: The attached patch extends Hibernate 2.0.3 to support all features of the Apache DBCP. I'm well aware that similiar patches (HBI-4, HB-51) have already been rejected, but unfortunately we need those extra-features in our project. In our setup the provider has set up a firewall between database and servlet-container that "kills" idle connections. Unfortunately it does a very bad job of it, so that we end up with a lot of connections that are not closed but are also not open anymore... In the end the whole system was hanging after a night of inactivity. By using the additional DBCP properties we were able to solve that problem. I would really appreciate if you add that patch to the system, because I don't like the idea of adding it manually to every new release of Hibernate and I think that other people might encounter similiar problems. Above all it's not a big change at all. Most people won't notice any difference, because we use the normal defaults, if no properties are supplied by the user. --------------------------------------------------------------------- JIRA INFORMATION: 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 If you want more information on JIRA, or have a bug to report see: http://www.atlassian.com/software/jira |
|
From: Juozas B. <ba...@ce...> - 2003-09-28 12:30:16
|
It must be bug in "SessionHolder".
----- Original Message -----
From: "Gavin King" <ga...@hi...>
To: "William R. Lorenz" <wr...@ex...>
Cc: <hib...@li...>;
<hib...@li...>
Sent: Saturday, September 27, 2003 1:48 PM
Subject: Re: [Hibernate] Hibernate Bug? [ConcurrentModificationException]
> We seem to be having some problems like this in more than one section
> of code. I really don't understand it at all; we suspect some kind of
> JVM bug. Unfortunately, no-one has been able to deliver a testcase
> that will help me reproduce this on my machine.
>
> I can't really do much, until I can reproduce it.
>
> P.S. You might also get this if you share a session between two
> threads - but at least some occurrences of this problem do not seem
> to be caused by this....
>
> William R. Lorenz wrote:
>
> >Fellow Hibernaters,
> >
> >I'm receiving an Exception in a Hibernate application I've built, and I'm
> >a bit confused as to why this might be happening. The code at where the
> >Exception is thrown is quite simple, and I think this might be a bug in
> >Hibernate itself. I've searched Google for this to no avail, and I'm
> >using the latest recommended Hibernate release as available on the site.
> >
> >The exception I receive has a stacktrace as follows:
> >
> > java.util.ConcurrentModificationException
> > at java.util.AbstractList$Itr.checkForComodification(Unknown Source)
> > at java.util.AbstractList$Itr.remove(Unknown Source)
> > at net.sf.hibernate.impl.SessionImpl.executeAll(SessionImpl.java:2101)
> > at net.sf.hibernate.impl.SessionImpl.execute(SessionImpl.java:2061)
> > at net.sf.hibernate.impl.SessionImpl.flush(SessionImpl.java:2005)
> > at net.sf.hibernate.transaction.JDBCTransaction.commit(
> > JDBCTransaction.java:57
> > )
> > at
org.express.ftpsrv.ConnectionHandler.<init>(ConnectionHandler.java:72)
> > at
org.express.ftpsrv.ConnectionListener.accept(ConnectionListener.java:56)
> > at
org.express.ftpsrv.ConnectionListener.main(ConnectionListener.java:19)
> >
> >And the code at ConnectionHandler.java:72 that causes this looks like:
> >
> > 52:this.ftpSession = new FtpSession();
> > 53:
> > 54:/* ftpSession.setSessionId() does not operate on the unique
> > 55: * 'id' field that is also part of the ftpSession object.
> > 56: */
> > 57:ftpSession.setSessionId(UniqueGenerator.makeUniqueNumber());
> > 58:
> > 59:Date currentDate = new Date();
> > 60:currentDate.setTime(System.currentTimeMillis());
> > 61:this.ftpSession.setBegTime(currentDate);
> > 62:
> > 63:net.sf.hibernate.Session hSession = null;
> > 64:Transaction transaction = null;
> > 65:
> > 66:try
> > 67:{
> > 68: hSession = SessionHolder.getSession();
> > 69:
> > 70: transaction = hSession.beginTransaction();
> > 71: hSession.save(this.session);
> > 72: transaction.commit();
> > 73:} catch (HibernateException e)
> > 74:{
> > 75: transaction.rollback();
> > 76:}
> >
> >I'd like to point out that this seems to be an intermittent thing,
> >occurring more often when I instantiate many objects quickly (the quoted
> >lines 52-72, above, are within a cronstructor in the Object).
> >
> >Does anyone have any ideas as to what might be happening or where I might
> >look for additional information in order to track down this bug?
> >
> >Thanks, in advance, for any response on this.
> >
> >-- _
> >__ __ ___ _| | William R. Lorenz <wr...@ex...>
> >\ V V / '_| | http://www.clevelandlug.net/ ; "Every revolution was
> > \./\./|_| |_| first a thought in one man's mind." - Ralph Waldo Emerson
> >
> >
> >
> >-------------------------------------------------------
> >This sf.net email is sponsored by:ThinkGeek
> >Welcome to geek heaven.
> >http://thinkgeek.com/sf
> >_______________________________________________
> >hibernate-devel mailing list
> >hib...@li...
> >https://lists.sourceforge.net/lists/listinfo/hibernate-devel
> >
> >
>
>
>
> -------------------------------------------------------
> This sf.net email is sponsored by:ThinkGeek
> Welcome to geek heaven.
> http://thinkgeek.com/sf
> _______________________________________________
> hibernate-devel mailing list
> hib...@li...
> https://lists.sourceforge.net/lists/listinfo/hibernate-devel
|
|
From: <leg...@at...> - 2003-09-28 03:54:49
|
The following comment has been added to this issue:
Author: Chris Nokleberg
Created: Sat, 27 Sep 2003 9:39 PM
Body:
> It is not a totally absurd idea
Thanks ;-)
Hope we can find a way to make this work.
Chris
---------------------------------------------------------------------
View the issue:
http://opensource.atlassian.com/projects/hibernate/secure/ViewIssue.jspa?key=HB-368
Here is an overview of the issue:
---------------------------------------------------------------------
Key: HB-368
Summary: Allow proxies to load in session other than one that created them
Type: Improvement
Status: Closed
Priority: Major
Resolution: REJECTED
Project: Hibernate2
Components:
core
Versions:
2.1
Assignee:
Reporter: Chris Nokleberg
Created: Sat, 27 Sep 2003 3:20 PM
Updated: Sat, 27 Sep 2003 3:42 PM
Description:
For discussion, please see the following forum topic:
http://forum.hibernate.org/viewtopic.php?t=42
In summary, there are scenarios in which it one may want proxies to be resolved in a different session.
The attached patch adds a ThreadLocal to SessionFactoryImpl which keeps track of the last opened session. If a the session that created a proxy is closed when it comes time to initialize the proxy, the last opened session is used instead, unless it has been closed as well.
---------------------------------------------------------------------
JIRA INFORMATION:
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
If you want more information on JIRA, or have a bug to report see:
http://www.atlassian.com/software/jira
|
|
From: <leg...@at...> - 2003-09-28 00:08:30
|
Message:
The following issue has been closed.
Resolver: Max Rydahl Andersen
Date: Sat, 27 Sep 2003 7:07 PM
Fixed in cvs
---------------------------------------------------------------------
View the issue:
http://opensource.atlassian.com/projects/hibernate/secure/ViewIssue.jspa?key=HB-353
Here is an overview of the issue:
---------------------------------------------------------------------
Key: HB-353
Summary: query.setProperty( Object ) assumes HQL
Type: Bug
Status: Closed
Priority: Major
Resolution: FIXED
Project: Hibernate2
Components:
core
Fix Fors:
2.1
Versions:
2.1
Assignee: Max Rydahl Andersen
Reporter: Christopher D Riccio
Created: Mon, 22 Sep 2003 12:58 PM
Updated: Sat, 27 Sep 2003 7:07 PM
Environment: DB2 Database
Description:
Here's what I have.
QUERY
select {d.*}
from department {d}
where {d}.deptno = :deptno
passing in an object (Department) which has a
private String deptno;
on it.
Getting the following Exception:
net.sf.hibernate.QueryException: in expected: {d} [select {d.*}
from department {d}
where {d}.deptno = :deptno]
{d} is defined in my query object.
When I do
Query.setString( "deptno", department.getDeptno() );
The query executes correctly.
After looking deeper into this.
Seems as if it is handling the Native sql call as HQL.
The query dies after parsing "department."
it's expecting a class path, ( saw indexOf( '.' ) so I assume that is what was going on). Then it sets expectingIn to true. The next thing it sees is {d} and it chokes on it.
---------------------------------------------------------------------
JIRA INFORMATION:
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
If you want more information on JIRA, or have a bug to report see:
http://www.atlassian.com/software/jira
|
|
From: <leg...@at...> - 2003-09-28 00:08:30
|
Message:
The following issue has been closed.
Resolver: Max Rydahl Andersen
Date: Sat, 27 Sep 2003 7:06 PM
fixed in cvs
---------------------------------------------------------------------
View the issue:
http://opensource.atlassian.com/projects/hibernate/secure/ViewIssue.jspa?key=HB-352
Here is an overview of the issue:
---------------------------------------------------------------------
Key: HB-352
Summary: Method introsepction fails with certain class property names
Type: Bug
Status: Closed
Priority: Minor
Resolution: FIXED
Project: Hibernate2
Components:
core
Fix Fors:
2.1
Versions:
2.0.3
Assignee: Max Rydahl Andersen
Reporter: Tom Pierce
Created: Mon, 22 Sep 2003 11:24 AM
Updated: Sat, 27 Sep 2003 7:06 PM
Environment: JDK 1.4.0_01, Windows 2000, DB2 7.2
Description:
When you have a class that has a property with a name like "eMailTxtDesc", and a getter signature like "public java.lang.String getEMailTxtDesc()", Hibernate will report the following exception at runtime: "net.sf.hibernate.PropertyNotFoundException: Could not find a getter for eMailTxtDesc in class com.fritolay.sia.model.TargtList".
I believe this is because the call to Introspector.decapitalize on line 242 of the ReflectHelper class doesn't actually decapitalize the "EMailTxtDesc" fragment. It is the same before and after the call. So, the test on line 244 fails.
I'm guessing my property name should actually be emailTxtDesc and the getter should be getEmailTxtDesc to be more bean-like. However, the mapping was autogenerated by Middlegen 2.0-b1 and the class files from the mappings were generated by hbm2java.
My work-around is to rename the property and the get/set pair.
---------------------------------------------------------------------
JIRA INFORMATION:
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
If you want more information on JIRA, or have a bug to report see:
http://www.atlassian.com/software/jira
|
|
From: <leg...@at...> - 2003-09-27 23:02:21
|
Message:
The following issue has been closed.
Resolver: Gavin King
Date: Sat, 27 Sep 2003 6:00 PM
There would have been a message in the log. Perhaps we should make Hibernate throw exception when XML validation fails.
---------------------------------------------------------------------
View the issue:
http://opensource.atlassian.com/projects/hibernate/secure/ViewIssue.jspa?key=HB-141
Here is an overview of the issue:
---------------------------------------------------------------------
Key: HB-141
Summary: NullpointerException
Type: Bug
Status: Closed
Priority: Major
Resolution: WON'T FIX
Project: Hibernate2
Versions:
2.0 final
Assignee:
Reporter: Mathias Bogaert
Created: Wed, 18 Jun 2003 10:58 AM
Updated: Sat, 27 Sep 2003 6:00 PM
Description:
Probably a bug in my own XML files, but a nullpointer is always wrong:
java.lang.NullPointerException
at net.sf.hibernate.cfg.Binder.getTypeFromXML(Binder.java:762)
at net.sf.hibernate.cfg.Binder.bindValue(Binder.java:348)
at net.sf.hibernate.cfg.Binder.bindIntegerValue(Binder.java:489)
at net.sf.hibernate.cfg.Binder.bindListSecondPass(Binder.java:919)
at net.sf.hibernate.cfg.Binder$ListSecondPass.secondPass(Binder.java:1178)
at net.sf.hibernate.cfg.Binder$SecondPass.doSecondPass(Binder.java:1116)
at net.sf.hibernate.cfg.Configuration.secondPassCompile(Configuration.java:495)
at net.sf.hibernate.cfg.Configuration.generateSchemaUpdateScript(Configuration.java:433)
at net.sf.hibernate.tool.hbm2ddl.SchemaUpdate.execute(SchemaUpdate.java:105)
at com.intrasoft.persistence.hibernate.HibernatePersistenceManager.buildSessionFactory(HibernatePersistenceManager.java:59)
at com.intrasoft.persistence.hibernate.HibernatePersistenceManager.init(HibernatePersistenceManager.java:38)
at com.opensymphony.xwork.interceptor.component.DefaultComponentManager.loadResource(DefaultComponentManager.java:152)
at com.opensymphony.xwork.interceptor.component.DefaultComponentManager.loadResource(DefaultComponentManager.java:137)
at com.opensymphony.xwork.interceptor.component.DefaultComponentManager.loadResource(DefaultComponentManager.java:137)
at com.opensymphony.xwork.interceptor.component.DefaultComponentManager.initializeComponent(DefaultComponentManager.java:73)
at com.opensymphony.xwork.interceptor.component.ComponentInterceptor.before(ComponentInterceptor.java:29)
at com.opensymphony.xwork.interceptor.AbstractInterceptor.intercept(AbstractInterceptor.java:36)
at com.opensymphony.xwork.DefaultActionInvocation.invoke(DefaultActionInvocation.java:148)
at com.opensymphony.xwork.interceptor.AbstractInterceptor.intercept(AbstractInterceptor.java:37)
at com.opensymphony.xwork.DefaultActionInvocation.invoke(DefaultActionInvocation.java:148)
at com.opensymphony.xwork.interceptor.AbstractInterceptor.intercept(AbstractInterceptor.java:37)
at com.opensymphony.xwork.DefaultActionInvocation.invoke(DefaultActionInvocation.java:148)
at com.opensymphony.xwork.interceptor.AbstractInterceptor.intercept(AbstractInterceptor.java:37)
at com.opensymphony.xwork.DefaultActionInvocation.invoke(DefaultActionInvocation.java:148)
at com.opensymphony.xwork.interceptor.AbstractInterceptor.intercept(AbstractInterceptor.java:37)
at com.opensymphony.xwork.DefaultActionInvocation.invoke(DefaultActionInvocation.java:148)
at com.opensymphony.xwork.interceptor.TimerInterceptor.intercept(TimerInterceptor.java:66)
at com.opensymphony.xwork.DefaultActionInvocation.invoke(DefaultActionInvocation.java:148)
at com.opensymphony.xwork.DefaultActionProxy.execute(DefaultActionProxy.java:108)
at com.opensymphony.webwork.dispatcher.ServletDispatcher.service(ServletDispatcher.java:164)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:1264)
at com.caucho.server.http.FilterChainServlet.doFilter(FilterChainServlet.java:96)
at com.opensymphony.module.sitemesh.filter.PageFilter.parsePage(PageFilter.java:129)
at com.opensymphony.module.sitemesh.filter.PageFilter.doFilter(PageFilter.java:61)
at com.caucho.server.http.FilterChainFilter.doFilter(FilterChainFilter.java:88)
at com.intrasoft.security.LoginFilter.doFilter(LoginFilter.java:82)
at com.caucho.server.http.FilterChainFilter.doFilter(FilterChainFilter.java:88)
at com.intrasoft.security.SecurityFilter.doFilter(SecurityFilter.java:34)
at com.caucho.server.http.FilterChainFilter.doFilter(FilterChainFilter.java:88)
at com.opensymphony.webwork.lifecycle.RequestLifecycleFilter.doFilter(RequestLifecycleFilter.java:61)
at com.caucho.server.http.FilterChainFilter.doFilter(FilterChainFilter.java:88)
at com.caucho.server.http.Invocation.service(Invocation.java:315)
at com.caucho.server.http.CacheInvocation.service(CacheInvocation.java:135)
at com.caucho.server.http.HttpRequest.handleRequest(HttpRequest.java:246)
at com.caucho.server.http.HttpRequest.handleConnection(HttpRequest.java:163)
at com.caucho.server.TcpConnection.run(TcpConnection.java:139)
at java.lang.Thread.run(Thread.java:534)
---------------------------------------------------------------------
JIRA INFORMATION:
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
If you want more information on JIRA, or have a bug to report see:
http://www.atlassian.com/software/jira
|
|
From: <leg...@at...> - 2003-09-27 22:58:20
|
Message:
The following issue has been closed.
Resolver: Gavin King
Date: Sat, 27 Sep 2003 5:56 PM
The user did not respond, so closing this issue.
---------------------------------------------------------------------
View the issue:
http://opensource.atlassian.com/projects/hibernate/secure/ViewIssue.jspa?key=HB-259
Here is an overview of the issue:
---------------------------------------------------------------------
Key: HB-259
Summary: HQL queries doesn't work with compositeIds composed by others compositeIds
Type: Bug
Status: Closed
Priority: Minor
Resolution: REJECTED
Project: Hibernate2
Versions:
2.0 final
2.0.1
2.0.2
Assignee:
Reporter: benoit lafontaine
Created: Thu, 14 Aug 2003 8:07 AM
Updated: Sat, 27 Sep 2003 5:56 PM
Description:
With the following mapping (and corresponding classes) the query :
SELECT a.id, a.libelleLong, a.categorieProduit.id.secteurEditorial.id.editeur.id FROM a in class Article WHERE a.categorieProduit.id.secteurEditorial.id.editeur.id = '150'
does not work (and should).
--------------------------------
Article.hbm.xml
<?xml version="1.0"?>
<!DOCTYPE hibernate-mapping PUBLIC
"-//Hibernate/Hibernate Mapping DTD 2.0//EN"
"http://hibernate.sourceforge.net/hibernate-mapping-2.0.dtd"> />
<hibernate-mapping>
<class
name="exemple.articles.Article"
table="LPR_PROD_DIST"
proxy="exemple.articles.Article"
dynamic-update="false"
mutable="false"
>
<jcs-cache usage="read-only" />
<id
name="id"
column="NPROD"
type="java.lang.String"
unsaved-value="none"
>
<generator class="assigned">
</generator>
</id>
<property
name="libelleLong"
type="java.lang.String"
update="true"
insert="true"
column="LIBLONG"
/>
<many-to-one
name="categorieProduit"
class="exemple.articles.CategorieProduit"
cascade="none"
outer-join="auto"
update="true"
insert="true"
>
<column
name="CATPROD"
/>
<column
name="SECTED"
/>
<column
name="EDITR"
/>
</many-to-one>
</class>
</hibernate-mapping>
------------------------------------------
categorieProduit :
<?xml version="1.0"?>
<!DOCTYPE hibernate-mapping PUBLIC
"-//Hibernate/Hibernate Mapping DTD 2.0//EN"
"http://hibernate.sourceforge.net/hibernate-mapping-2.0.dtd"> />
<hibernate-mapping>
<class
name="exemple.articles.CategorieProduit"
table="LPR_CATG_PRODUIT"
dynamic-update="false"
mutable="false"
proxy="exemple.articles.CategorieProduit"
>
<jcs-cache usage="read-only" />
<composite-id
name="id"
class="exemple.articles.CategorieProduitCompositeId"
unsaved-value="none"
>
<key-property
name="categorieProduitId"
type="int"
column="CATPROD"
/>
<key-many-to-one
name="secteurEditorial"
class="exemple.articles.SecteurEditorial"
>
<column name="SECTED"/>
<column name="EDITR"/>
</key-many-to-one>
</composite-id>
<property
name="libelleLong"
type="java.lang.String"
update="true"
insert="true"
column="LIBLONG"
/>
</class>
</hibernate-mapping>
---------------------------------------
secteurEditorial
<?xml version="1.0"?>
<!DOCTYPE hibernate-mapping PUBLIC
"-//Hibernate/Hibernate Mapping DTD 2.0//EN"
"http://hibernate.sourceforge.net/hibernate-mapping-2.0.dtd"> />
<hibernate-mapping>
<class
name="exemple.articles.SecteurEditorial"
table="LPR_SECT_EDITORIAL"
dynamic-update="false"
mutable="false"
>
<jcs-cache usage="read-only" />
<composite-id
name="id"
class="exemple.articles.SecteurEditorialCompositeId"
unsaved-value="none"
>
<key-property
name="secteurEditorialId"
type="int"
column="SECTED"
/>
<key-many-to-one
name="editeur"
class="exemple.articles.Editeur"
column="EDITR"
/>
</composite-id>
<property
name="libelleLong"
type="java.lang.String"
update="true"
insert="true"
column="LIBLONG"
/>
</class>
</hibernate-mapping>
------------------------------------------
editeur:
<?xml version="1.0"?>
<!DOCTYPE hibernate-mapping PUBLIC
"-//Hibernate/Hibernate Mapping DTD 2.0//EN"
"http://hibernate.sourceforge.net/hibernate-mapping-2.0.dtd"> />
<hibernate-mapping>
<class
name="exemple.articles.Editeur"
table="LPR_EDITEUR"
dynamic-update="false"
mutable="false"
>
<jcs-cache usage="read-only" />
<id
name="id"
column="EDITR"
type="java.lang.String"
unsaved-value="none"
>
<generator class="assigned">
</generator>
</id>
<property
name="nom"
type="java.lang.String"
update="true"
insert="true"
column="LEDIT1"
/>
</class>
</hibernate-mapping>
---------------------------------------------------------------------
JIRA INFORMATION:
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
If you want more information on JIRA, or have a bug to report see:
http://www.atlassian.com/software/jira
|
|
From: <leg...@at...> - 2003-09-27 22:48:10
|
Message:
The following issue has been closed.
Resolver: Max Rydahl Andersen
Date: Sat, 27 Sep 2003 5:46 PM
finally commited this one
---------------------------------------------------------------------
View the issue:
http://opensource.atlassian.com/projects/hibernate/secure/ViewIssue.jspa?key=HB-176
Here is an overview of the issue:
---------------------------------------------------------------------
Key: HB-176
Summary: Allow for Dialect specific seperator between schema and table name
Type: Patch
Status: Closed
Priority: Trivial
Resolution: FIXED
Project: Hibernate2
Components:
core
Fix Fors:
2.1
Versions:
2.0.2
Assignee: Max Rydahl Andersen
Reporter: Chris Hane
Created: Thu, 10 Jul 2003 3:02 PM
Updated: Sat, 27 Sep 2003 5:46 PM
Description:
I'm on the receiving end of a Hibernate mapping file(s) that use the schema attributes. However, I am using MySQL which does not support schema (at least with the dot notation).
I added to Dialect:
getSchemaSeperator which will supply the default seperator found in Table (StringHelper.DOT).
In MySQLDialect I overrode this function to provide StringHelper.UNDERSCORE
I modified Table to use the new attribute from Dialect in getQualifiedName()
The source I modified was the latest (2003-07-10) pulled from CVS.
Chris....
---------------------------------------------------------------------
JIRA INFORMATION:
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
If you want more information on JIRA, or have a bug to report see:
http://www.atlassian.com/software/jira
|
|
From: <leg...@at...> - 2003-09-27 21:08:22
|
The following comment has been added to this issue:
Author: Max Rydahl Andersen
Created: Sat, 27 Sep 2003 4:06 PM
Body:
Sitting here with Gavin talking about it right now ;)
It is not a totally absurd idea, but it really opens up for some "spookey" error situations.
---------------------------------------------------------------------
View the issue:
http://opensource.atlassian.com/projects/hibernate/secure/ViewIssue.jspa?key=HB-368
Here is an overview of the issue:
---------------------------------------------------------------------
Key: HB-368
Summary: Allow proxies to load in session other than one that created them
Type: Improvement
Status: Closed
Priority: Major
Resolution: REJECTED
Project: Hibernate2
Components:
core
Versions:
2.1
Assignee:
Reporter: Chris Nokleberg
Created: Sat, 27 Sep 2003 3:20 PM
Updated: Sat, 27 Sep 2003 3:42 PM
Description:
For discussion, please see the following forum topic:
http://forum.hibernate.org/viewtopic.php?t=42
In summary, there are scenarios in which it one may want proxies to be resolved in a different session.
The attached patch adds a ThreadLocal to SessionFactoryImpl which keeps track of the last opened session. If a the session that created a proxy is closed when it comes time to initialize the proxy, the last opened session is used instead, unless it has been closed as well.
---------------------------------------------------------------------
JIRA INFORMATION:
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
If you want more information on JIRA, or have a bug to report see:
http://www.atlassian.com/software/jira
|
|
From: <leg...@at...> - 2003-09-27 21:06:23
|
The following comment has been added to this issue:
Author: Gavin King
Created: Sat, 27 Sep 2003 4:04 PM
Body:
> And there is no way to implement a backpointer from the
> collection to its owner.
I wonder why I wrote this. I can't quite remember what the problem is.
---------------------------------------------------------------------
View the issue:
http://opensource.atlassian.com/projects/hibernate/secure/ViewIssue.jspa?key=HB-368
Here is an overview of the issue:
---------------------------------------------------------------------
Key: HB-368
Summary: Allow proxies to load in session other than one that created them
Type: Improvement
Status: Closed
Priority: Major
Resolution: REJECTED
Project: Hibernate2
Components:
core
Versions:
2.1
Assignee:
Reporter: Chris Nokleberg
Created: Sat, 27 Sep 2003 3:20 PM
Updated: Sat, 27 Sep 2003 3:42 PM
Description:
For discussion, please see the following forum topic:
http://forum.hibernate.org/viewtopic.php?t=42
In summary, there are scenarios in which it one may want proxies to be resolved in a different session.
The attached patch adds a ThreadLocal to SessionFactoryImpl which keeps track of the last opened session. If a the session that created a proxy is closed when it comes time to initialize the proxy, the last opened session is used instead, unless it has been closed as well.
---------------------------------------------------------------------
JIRA INFORMATION:
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
If you want more information on JIRA, or have a bug to report see:
http://www.atlassian.com/software/jira
|
|
From: <leg...@at...> - 2003-09-27 21:04:20
|
The following comment has been added to this issue:
Author: Gavin King
Created: Sat, 27 Sep 2003 4:03 PM
Body:
Chris, Max and I are discussing this (in Aarhus).
I think we would accept something like this if:
(1) it worked by calling Session.lock()
(2) it worked for collections (which would require that a collection wrapper keep a pointer back to the owning entity, so that it could lock() the owner)
(3) we could turn this feature off
---------------------------------------------------------------------
View the issue:
http://opensource.atlassian.com/projects/hibernate/secure/ViewIssue.jspa?key=HB-368
Here is an overview of the issue:
---------------------------------------------------------------------
Key: HB-368
Summary: Allow proxies to load in session other than one that created them
Type: Improvement
Status: Closed
Priority: Major
Resolution: REJECTED
Project: Hibernate2
Components:
core
Versions:
2.1
Assignee:
Reporter: Chris Nokleberg
Created: Sat, 27 Sep 2003 3:20 PM
Updated: Sat, 27 Sep 2003 3:42 PM
Description:
For discussion, please see the following forum topic:
http://forum.hibernate.org/viewtopic.php?t=42
In summary, there are scenarios in which it one may want proxies to be resolved in a different session.
The attached patch adds a ThreadLocal to SessionFactoryImpl which keeps track of the last opened session. If a the session that created a proxy is closed when it comes time to initialize the proxy, the last opened session is used instead, unless it has been closed as well.
---------------------------------------------------------------------
JIRA INFORMATION:
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
If you want more information on JIRA, or have a bug to report see:
http://www.atlassian.com/software/jira
|
|
From: <leg...@at...> - 2003-09-27 20:58:19
|
The following comment has been added to this issue:
Author: Chris Nokleberg
Created: Sat, 27 Sep 2003 3:58 PM
Body:
FYI here is Gavin's comment on this issue:
http://www.mail-archive.com/hib...@li.../msg00041.html
> I guess, we *could* implement ThreadLocalSession internally in
> Hibernate so that proxies and lazy collections _automatically_ pick up
> a reference to the current Session. But I've so far resisted this
> design. It doesn't work too well for collections, since they can't be
> reassociated with a new Session without their current owner also being
> reassociated. And there is no way to implement a backpointer from the
> collection to its owner.
I'm interested in more detail regarding the collection problem. I have some ideas but need more information...
---------------------------------------------------------------------
View the issue:
http://opensource.atlassian.com/projects/hibernate/secure/ViewIssue.jspa?key=HB-368
Here is an overview of the issue:
---------------------------------------------------------------------
Key: HB-368
Summary: Allow proxies to load in session other than one that created them
Type: Improvement
Status: Closed
Priority: Major
Resolution: REJECTED
Project: Hibernate2
Components:
core
Versions:
2.1
Assignee:
Reporter: Chris Nokleberg
Created: Sat, 27 Sep 2003 3:20 PM
Updated: Sat, 27 Sep 2003 3:42 PM
Description:
For discussion, please see the following forum topic:
http://forum.hibernate.org/viewtopic.php?t=42
In summary, there are scenarios in which it one may want proxies to be resolved in a different session.
The attached patch adds a ThreadLocal to SessionFactoryImpl which keeps track of the last opened session. If a the session that created a proxy is closed when it comes time to initialize the proxy, the last opened session is used instead, unless it has been closed as well.
---------------------------------------------------------------------
JIRA INFORMATION:
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
If you want more information on JIRA, or have a bug to report see:
http://www.atlassian.com/software/jira
|
|
From: <leg...@at...> - 2003-09-27 20:49:20
|
The following comment has been added to this issue:
Author: Chris Nokleberg
Created: Sat, 27 Sep 2003 3:48 PM
Body:
This patch does not open a new session to fetch the proxy data, it simply uses the current session if there is already one open. If there is no open session an exception will be thrown just like happens now.
The workarounds you suggest are not acceptable for the same reason that it is infeasible to initialize all proxies before sending them to the view layer--they may be contained within an arbitrarily complex object model.
I'm happy to help find a workaround for the technical issue of lazy loaded collections (I don't think it is impossible).
---------------------------------------------------------------------
View the issue:
http://opensource.atlassian.com/projects/hibernate/secure/ViewIssue.jspa?key=HB-368
Here is an overview of the issue:
---------------------------------------------------------------------
Key: HB-368
Summary: Allow proxies to load in session other than one that created them
Type: Improvement
Status: Closed
Priority: Major
Resolution: REJECTED
Project: Hibernate2
Components:
core
Versions:
2.1
Assignee:
Reporter: Chris Nokleberg
Created: Sat, 27 Sep 2003 3:20 PM
Updated: Sat, 27 Sep 2003 3:42 PM
Description:
For discussion, please see the following forum topic:
http://forum.hibernate.org/viewtopic.php?t=42
In summary, there are scenarios in which it one may want proxies to be resolved in a different session.
The attached patch adds a ThreadLocal to SessionFactoryImpl which keeps track of the last opened session. If a the session that created a proxy is closed when it comes time to initialize the proxy, the last opened session is used instead, unless it has been closed as well.
---------------------------------------------------------------------
JIRA INFORMATION:
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
If you want more information on JIRA, or have a bug to report see:
http://www.atlassian.com/software/jira
|
|
From: <leg...@at...> - 2003-09-27 20:42:20
|
Message:
The following issue has been closed.
Resolver: Max Rydahl Andersen
Date: Sat, 27 Sep 2003 3:42 PM
We can't encourage building systems that randomly goes of an reopens, reconnect, reaccess the database when you have just explicitly closed the access. It's just not a good idea!
Furthermore it won't ever work for collection wrappers, only for proxies.
You should/could instead reassociate the objects/proxies with a new session by using saveOrUpdate() or even better lock(o, LockMode.NONE); which will reattach the object without performing any save or updates.
---------------------------------------------------------------------
View the issue:
http://opensource.atlassian.com/projects/hibernate/secure/ViewIssue.jspa?key=HB-368
Here is an overview of the issue:
---------------------------------------------------------------------
Key: HB-368
Summary: Allow proxies to load in session other than one that created them
Type: Improvement
Status: Closed
Priority: Major
Resolution: REJECTED
Project: Hibernate2
Components:
core
Versions:
2.1
Assignee:
Reporter: Chris Nokleberg
Created: Sat, 27 Sep 2003 3:20 PM
Updated: Sat, 27 Sep 2003 3:42 PM
Description:
For discussion, please see the following forum topic:
http://forum.hibernate.org/viewtopic.php?t=42
In summary, there are scenarios in which it one may want proxies to be resolved in a different session.
The attached patch adds a ThreadLocal to SessionFactoryImpl which keeps track of the last opened session. If a the session that created a proxy is closed when it comes time to initialize the proxy, the last opened session is used instead, unless it has been closed as well.
---------------------------------------------------------------------
JIRA INFORMATION:
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
If you want more information on JIRA, or have a bug to report see:
http://www.atlassian.com/software/jira
|
|
From: <leg...@at...> - 2003-09-27 20:23:30
|
The following issue has been updated:
Updater: Chris Nokleberg (mailto:ch...@si...)
Date: Sat, 27 Sep 2003 3:21 PM
Comment:
Patch to make proxies use last opened session as a fallback when initializing.
Changes:
Attachment changed to lazypatch.txt
---------------------------------------------------------------------
For a full history of the issue, see:
http://opensource.atlassian.com/projects/hibernate/secure/ViewIssue.jspa?key=HB-368&page=history
---------------------------------------------------------------------
View the issue:
http://opensource.atlassian.com/projects/hibernate/secure/ViewIssue.jspa?key=HB-368
Here is an overview of the issue:
---------------------------------------------------------------------
Key: HB-368
Summary: Allow proxies to load in session other than one that created them
Type: Improvement
Status: Unassigned
Priority: Major
Project: Hibernate2
Components:
core
Versions:
2.1
Assignee:
Reporter: Chris Nokleberg
Created: Sat, 27 Sep 2003 3:20 PM
Updated: Sat, 27 Sep 2003 3:21 PM
Description:
For discussion, please see the following forum topic:
http://forum.hibernate.org/viewtopic.php?t=42
In summary, there are scenarios in which it one may want proxies to be resolved in a different session.
The attached patch adds a ThreadLocal to SessionFactoryImpl which keeps track of the last opened session. If a the session that created a proxy is closed when it comes time to initialize the proxy, the last opened session is used instead, unless it has been closed as well.
---------------------------------------------------------------------
JIRA INFORMATION:
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
If you want more information on JIRA, or have a bug to report see:
http://www.atlassian.com/software/jira
|
|
From: <leg...@at...> - 2003-09-27 20:22:25
|
Message: A new issue has been created in JIRA. --------------------------------------------------------------------- View the issue: http://opensource.atlassian.com/projects/hibernate/secure/ViewIssue.jspa?key=HB-368 Here is an overview of the issue: --------------------------------------------------------------------- Key: HB-368 Summary: Allow proxies to load in session other than one that created them Type: Improvement Status: Unassigned Priority: Major Project: Hibernate2 Components: core Versions: 2.1 Assignee: Reporter: Chris Nokleberg Created: Sat, 27 Sep 2003 3:20 PM Updated: Sat, 27 Sep 2003 3:20 PM Description: For discussion, please see the following forum topic: http://forum.hibernate.org/viewtopic.php?t=42 In summary, there are scenarios in which it one may want proxies to be resolved in a different session. The attached patch adds a ThreadLocal to SessionFactoryImpl which keeps track of the last opened session. If a the session that created a proxy is closed when it comes time to initialize the proxy, the last opened session is used instead, unless it has been closed as well. --------------------------------------------------------------------- JIRA INFORMATION: 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 If you want more information on JIRA, or have a bug to report see: http://www.atlassian.com/software/jira |
|
From: Juozas B. <ba...@ce...> - 2003-09-27 18:46:21
|
Yes, it is problem in SessionHolder implementation, but it is trivial to
fix:
>
> 01:public class SessionHolder
> 02:{
> 03: private static final boolean DEBUG = true;
> 04: private static ThreadLocal session;
> 05:
> 06: public static Session getSession()
> 07: {
> 08: SessionHolder.connect();
> 09:
> 10: return((Session )SessionHolder.session.get());
> 11: }
> 12:
> 13: public static void connect()
> 14: {
> 15: if (SessionHolder.session.get() == null)
> 16: {
> 17: try
> 18: {
> 19: SessionFactory sessionFactory = new Configuration()
> 20: .configure().buildSessionFactory();
> 21: SessionHolder.session.set( sessionFactory.openSession() );
> 22: } catch (HibernateException e)
> 23: {
> 24: throw new RuntimeException(e);
}
> 26: }
}
> 34:
> 35: public static void disconnect()
> 36: {
> 37: if (SessionHolder.session.get() != null)
> 38: {
> 39: try
> 40: {
> 41: SessionHolder.session.close();
> 42: } catch (HibernateException e) {
throw new RuntimeException(e);
}
> 44: }
> 45: }
> 46:}
>
> QHat do you think? Is there a better way that I should be doing this
> without rewriting a heck of a lot of code? I like the idea of having the
> session establishment self-contained within the SessionHolder object?
>
> Does this SessionHolder seem to be the culprit behind the
> ConcurrentModificationException issues?
>
> > > We seem to be having some problems like this in more than one section
> > > of code. I really don't understand it at all; we suspect some kind of
> > > JVM bug. Unfortunately, no-one has been able to deliver a testcase
> > > that will help me reproduce this on my machine.
>
> > > I can't really do much, until I can reproduce it.
>
> > > P.S. You might also get this if you share a session between two
> > > threads - but at least some occurrences of this problem do not seem to
> > > be caused by this....
>
> > > >I'm receiving an Exception in a Hibernate application I've built, and
> > > >I'm a bit confused as to why this might be happening. The code at
> > > >where the Exception is thrown is quite simple, and I think this might
> > > >be a bug in Hibernate itself. I've searched Google for this to no
> > > >avail, and I'm using the latest recommended Hibernate release as
> > > >available on the site.
>
> > > >The exception I receive has a stacktrace as follows:
>
> > > > java.util.ConcurrentModificationException
> > > > at java.util.AbstractList$Itr.checkForComodification(Unknown
Source)
> > > > at java.util.AbstractList$Itr.remove(Unknown Source)
> > > > at
net.sf.hibernate.impl.SessionImpl.executeAll(SessionImpl.java:2101)
> > > > at net.sf.hibernate.impl.SessionImpl.execute(SessionImpl.java:2061)
> > > > at net.sf.hibernate.impl.SessionImpl.flush(SessionImpl.java:2005)
> > > > at net.sf.hibernate.transaction.JDBCTransaction.commit(
> > > > JDBCTransaction.java:57
> > > > )
> > > > at
> > org.express.ftpsrv.ConnectionHandler.<init>(ConnectionHandler.java:72)
> > > > at
> > org.express.ftpsrv.ConnectionListener.accept(ConnectionListener.java:56)
> > > > at
> > org.express.ftpsrv.ConnectionListener.main(ConnectionListener.java:19)
> > > >
> > > >And the code at ConnectionHandler.java:72 that causes this looks
like:
> > > >
> > > > 52:this.ftpSession = new FtpSession();
> > > > 53:
> > > > 54:/* ftpSession.setSessionId() does not operate on the unique
> > > > 55: * 'id' field that is also part of the ftpSession object.
> > > > 56: */
> > > > 57:ftpSession.setSessionId(UniqueGenerator.makeUniqueNumber());
> > > > 58:
> > > > 59:Date currentDate = new Date();
> > > > 60:currentDate.setTime(System.currentTimeMillis());
> > > > 61:this.ftpSession.setBegTime(currentDate);
> > > > 62:
> > > > 63:net.sf.hibernate.Session hSession = null;
> > > > 64:Transaction transaction = null;
> > > > 65:
> > > > 66:try
> > > > 67:{
> > > > 68: hSession = SessionHolder.getSession();
> > > > 69:
> > > > 70: transaction = hSession.beginTransaction();
> > > > 71: hSession.save(this.ftpSession);
> > > > 72: transaction.commit();
> > > > 73:} catch (HibernateException e)
> > > > 74:{
> > > > 75: transaction.rollback();
> > > > 76:}
>
> > > >I'd like to point out that this seems to be an intermittent thing,
> > > >occurring more often when I instantiate many objects quickly (the
> > > >quoted lines 52-72, above, are within a cronstructor in the Object).
>
> > > >Does anyone have any ideas as to what might be happening or where I
> > > >might look for additional information in order to track down this
> > > >bug? Thanks, in advance, for any response on this.
>
> -- _
> __ __ ___ _| | William R. Lorenz <wr...@ex...>
> \ V V / '_| | http://www.clevelandlug.net/ ; "Every revolution was
> \./\./|_| |_| first a thought in one man's mind." - Ralph Waldo Emerson
>
>
|
93 messages has been excluded from this view by a project administrator.
