[Hibernate-JIRA] Created: (HHH-4585) support generator = "uuid.hex" for @javax.persistence.GeneratedValue
by zhouyanming (JIRA)
support generator = "uuid.hex" for @javax.persistence.GeneratedValue
--------------------------------------------------------------------
Key: HHH-4585
URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-4585
Project: Hibernate Core
Issue Type: Improvement
Components: annotations
Affects Versions: 3.5.0-Beta-2
Reporter: zhouyanming
@javax.persistence.GeneratedValue(strategy = GenerationType.AUTO, generator = "uuid.hex")
will cause exception
Caused by: org.hibernate.AnnotationException: Unknown Id.generator: uuid.hex
at org.hibernate.cfg.BinderHelper.makeIdGenerator(BinderHelper.java:451)
at org.hibernate.cfg.AnnotationBinder.bindId(AnnotationBinder.java:2222)
at org.hibernate.cfg.AnnotationBinder.bindId(AnnotationBinder.java:2160)
at org.hibernate.cfg.AnnotationBinder.processElementAnnotations(AnnotationBinder.java:1426)
it must be
@javax.persistence.GeneratedValue(generator = "system-uuid")
@org.hibernate.annotations.GenericGenerator(name = "system-uuid", strategy = "uuid.hex")
it's intrusive depending hibernate api.
--
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, 5 months
[Hibernate-JIRA] Created: (HHH-2990) Bad usage of ClassLoader.loadClass() for Java6 in SerializationHelper$CustomObjectInputStream - deserialization bottleneck for arrays
by Tom Eicher (JIRA)
Bad usage of ClassLoader.loadClass() for Java6 in SerializationHelper$CustomObjectInputStream - deserialization bottleneck for arrays
-------------------------------------------------------------------------------------------------------------------------------------
Key: HHH-2990
URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-2990
Project: Hibernate3
Issue Type: Bug
Affects Versions: 3.2.5
Environment: Hibernate 3.2.5, Java 6 Sun (any), any platform (tested Linux x64, Mac x64 (J6dp1))
Reporter: Tom Eicher
Sun has "clarified" (others say modified) the API of "ClassLoader.loadClass()" and no longer allows this to be called for arrays, e.g. String[].
( see: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6500212 and duplicates )
and states that this has always been very unstable to use/do in the first place.
So trying to load an array of something using this method results in ClassNotFoundException.
The correct thing to do is call Class.forName(className,false,myClassLoader); instead of myClassLoader.loadClass(className);
In SerializationHelper$CustomObjectInputStream.resolveClass() we do
ClassLoader loader = Thread.currentThread().getContextClassLoader();
try {
resolvedClass = loader.loadClass(className);
log.trace("Class resolved through context class loader");
}
catch(ClassNotFoundException e) {
log.trace("Asking super to resolve");
resolvedClass = super.resolveClass(v);
}
which results in the deserialization process for a String[] always searching String[] in all the application's jars/wars/etc before really loading it.
The bad thing is, loadClass() is synchronized.
In our case, we have multiple threads loading database rows containing String[]s, which results in one Thread doing
INFO | jvm 1 | 2007/11/30 16:56:44 | java.lang.Thread.State: RUNNABLE
INFO | jvm 1 | 2007/11/30 16:56:44 | at java.util.zip.ZipFile.getEntry(Native Method)
INFO | jvm 1 | 2007/11/30 16:56:44 | at java.util.zip.ZipFile.getEntry(ZipFile.java:149)
INFO | jvm 1 | 2007/11/30 16:56:44 | - locked <0x00002aaab4047c20> (a java.util.jar.JarFile)
INFO | jvm 1 | 2007/11/30 16:56:44 | at java.util.jar.JarFile.getEntry(JarFile.java:206)
INFO | jvm 1 | 2007/11/30 16:56:44 | at java.util.jar.JarFile.getJarEntry(JarFile.java:189)
INFO | jvm 1 | 2007/11/30 16:56:44 | at sun.misc.URLClassPath$JarLoader.getResource(URLClassPath.java:754)
INFO | jvm 1 | 2007/11/30 16:56:44 | at sun.misc.URLClassPath.getResource(URLClassPath.java:168)
INFO | jvm 1 | 2007/11/30 16:56:44 | at java.net.URLClassLoader$1.run(URLClassLoader.java:192)
INFO | jvm 1 | 2007/11/30 16:56:44 | at java.security.AccessController.doPrivileged(Native Method)
INFO | jvm 1 | 2007/11/30 16:56:44 | at java.net.URLClassLoader.findClass(URLClassLoader.java:188)
INFO | jvm 1 | 2007/11/30 16:56:44 | at java.lang.ClassLoader.loadClass(ClassLoader.java:306)
INFO | jvm 1 | 2007/11/30 16:56:44 | - locked <0x00002aaab4025998> (a org.apache.catalina.loader.StandardClassLoader)
INFO | jvm 1 | 2007/11/30 16:56:44 | at java.lang.ClassLoader.loadClass(ClassLoader.java:299)
INFO | jvm 1 | 2007/11/30 16:56:44 | - locked <0x00002aaab4095a68> (a org.apache.catalina.loader.StandardClassLoader)
INFO | jvm 1 | 2007/11/30 16:56:44 | at java.lang.ClassLoader.loadClass(ClassLoader.java:251)
INFO | jvm 1 | 2007/11/30 16:56:44 | at org.apache.catalina.loader.WebappClassLoader.loadClass(WebappClassLoader.java:1346)
INFO | jvm 1 | 2007/11/30 16:56:44 | at org.apache.catalina.loader.WebappClassLoader.loadClass(WebappClassLoader.java:1205)
INFO | jvm 1 | 2007/11/30 16:56:44 | at org.hibernate.util.SerializationHelper$CustomObjectInputStream.resolveClass(SerializationHelper.java:263)
INFO | jvm 1 | 2007/11/30 16:56:44 | at java.io.ObjectInputStream.readNonProxyDesc(ObjectInputStream.java:1575)
INFO | jvm 1 | 2007/11/30 16:56:44 | at java.io.ObjectInputStream.readClassDesc(ObjectInputStream.java:1496)
INFO | jvm 1 | 2007/11/30 16:56:44 | at java.io.ObjectInputStream.readArray(ObjectInputStream.java:1624)
INFO | jvm 1 | 2007/11/30 16:56:44 | at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1323)
INFO | jvm 1 | 2007/11/30 16:56:44 | at java.io.ObjectInputStream.readObject(ObjectInputStream.java:351)
INFO | jvm 1 | 2007/11/30 16:56:44 | at org.hibernate.util.SerializationHelper.deserialize(SerializationHelper.java:210)
and all other threads doing nothing
INFO | jvm 1 | 2007/11/30 16:56:44 | java.lang.Thread.State: BLOCKED (on object monitor)
INFO | jvm 1 | 2007/11/30 16:56:44 | at java.lang.ClassLoader.loadClass(ClassLoader.java:295)
INFO | jvm 1 | 2007/11/30 16:56:44 | - waiting to lock <0x00002aaab4095a68> (a org.apache.catalina.loader.StandardClassLoader)
INFO | jvm 1 | 2007/11/30 16:56:44 | at java.lang.ClassLoader.loadClass(ClassLoader.java:251)
INFO | jvm 1 | 2007/11/30 16:56:44 | at org.apache.catalina.loader.WebappClassLoader.loadClass(WebappClassLoader.java:1346)
INFO | jvm 1 | 2007/11/30 16:56:44 | at org.apache.catalina.loader.WebappClassLoader.loadClass(WebappClassLoader.java:1205)
INFO | jvm 1 | 2007/11/30 16:56:44 | at org.hibernate.util.SerializationHelper$CustomObjectInputStream.resolveClass(SerializationHelper.java:263)
INFO | jvm 1 | 2007/11/30 16:56:44 | at java.io.ObjectInputStream.readNonProxyDesc(ObjectInputStream.java:1575)
(rest of stack trace identical to above)
This can easily be worked around by setting the compatibility property
-Dsun.lang.ClassLoader.allowArraySyntax=true
however a) this workaround might not be around for long and b) most people will never find this bottleneck, therefore will not apply the workaround.
For our case, we got a 35% performance increase just be setting this property (and not a single loadClass() or ZipFile.getEntry() in any thread dump any more).
Cheers, Tom.
--
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, 5 months
[Hibernate-JIRA] Updated: (HHH-1395) Hierarchical entity data management using 'modified preorder tree traversal algorithm' (nested set trees)
by Joonas Koivunen (JIRA)
[ http://opensource.atlassian.com/projects/hibernate/browse/HHH-1395?page=c... ]
Joonas Koivunen updated HHH-1395:
---------------------------------
Attachment: utils-parent-20091117.tar.gz
A nested set implementation building on top of Christians.
Modification summary:
* package changed to org.hibernate.utils.nestedset
* use slf4j for logging
* add support for changing parent of a node
* give stateless session to executeInMemory() in NestedSetOperation
The package extracts as a maven project "utils-parent" which includes module "utils-nestedset".
To compile it use "mvn compile" in the utils-parent directory.
To get a jar out of it use "mvn package" and get the jar from utils-parent/utils-nestedset/target.
All the modifications and added code released under LGPL 2.1.
If you have any problems you can find me at #hibernate by nick reisi or comment on this jira issue.
> Hierarchical entity data management using 'modified preorder tree traversal algorithm' (nested set trees)
> ----------------------------------------------------------------------------------------------------------
>
> Key: HHH-1395
> URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-1395
> Project: Hibernate Core
> Issue Type: New Feature
> Components: core, query-hql
> Environment: Hibernate 3.1 plus Annotations extending EJB3 implementation
> Reporter: James Salt
> Attachments: nestedset.tar.gz, utils-parent-20091117.tar.gz
>
> Original Estimate: 3 weeks
> Remaining Estimate: 3 weeks
>
> An enhancement to allow entities to exist in a managed tree (DAG) structure, via the use of property annotations and entity annotations. With an extension to the HQL language to mimic the Oracle recusive query clause.
> This would be classically be useful for Bill of Material uses, or any tree like entity structure.
> I have implemented a homebrew approach using the 'adjacency list method' , and a post persist call back method to set the node path. Although I think a more full blown optimised algorithm would be the 'modified preorder tree traversal algorithm'.
> In the annotations world this could be implemented using an annotation like @Hierarchical to the entity, with a @Parent (mask for @ManyToOne) annotation on the parent field/parameter and @Children (mask for @OneToMany) annotation on the list of children entities.
> Then a postupdate method could be implemented for the entity type, that recalculates the tree meta data -i.e. parent, left and right.
> I believe this would be a valuable extension (useful for many common data models) to the hibernate core product that could be exposed through annotations as I have discussed and the hbm.xml.
> The users of such a system would be aware of the performance implications on insert/update/delete, but gain a massive performance gain on querying a tree data model.
>
--
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, 5 months
[Hibernate-JIRA] Commented: (HHH-1395) Hierarchical entity data management using 'modified preorder tree traversal algorithm' (nested set trees)
by Joonas Koivunen (JIRA)
[ http://opensource.atlassian.com/projects/hibernate/browse/HHH-1395?page=c... ]
Joonas Koivunen commented on HHH-1395:
--------------------------------------
Actually I've found that the post-update event _is_ the way to go.
I'm yet to formulate a proper patch against the Christians version above, but the solution is:
* add post-load -eventlistener, catch NestedSetNode<?> entities, set a property "persistentParent"
{code}
if (event.getEntity() instanceof NestedSetNode<?>)
(NestedSetNode)event.getEntity().setPersistentParent( ((NestedSetNode)event.getEntity()).getParent());
{code}
* add post-update -eventlistener, which uses the "persistentParent" property to first find out whether or not the parent has changed
** if the parent *was* null but is no longer, joins the node into parent's tree (sort of like insert operation)
** if the parent *was* not null but is null, detaches the node
** if the parent *was* not null but is not null and not same, detaches the node and joins
The detach operation has 3 operations:
# set new ns_thread and add correction *c* to ns_left and ns_right, where {{long c = 1 - node.getNsLeft();}}
# fix previous threads nodes TO THE RIGHT (excluding previous parents of node):
#* add correction c to both ns_left and ns_right, where {{long c = -2 * updatedInThePreviousQuery;}}
# fix previous thread parent hierarchy (all parents in the previous node):
#* add correction c to ns_right (c is the same)
The join operation has 4 operations:
# setup the joined tree:
#* add correction c to both ns_left and ns_right, where {{ long c = newParent.getNsRight() - 1; }}
# fix up the new parent tree with nodes TO THE RIGHT by the insertion point
#* add correction c to both ns_left and ns_right, where {{ long c = 2 * updatedInThePreviousQuery;}}
# fix up the new parent trees new parents
#* add correction c to ns_right (c is the same)
# fix the joined tree thread_id as new tree's thread id
Simple as that :) Watch this space for a patch.
Also, if someone was interested in formulating a hibernate-3.5 style tests for this one maybe perhaps this might get someday into main tree.. I've got no idea how to do those, as in fact I haven't yet look at any of the tests in the 3.5 series..
> Hierarchical entity data management using 'modified preorder tree traversal algorithm' (nested set trees)
> ----------------------------------------------------------------------------------------------------------
>
> Key: HHH-1395
> URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-1395
> Project: Hibernate Core
> Issue Type: New Feature
> Components: core, query-hql
> Environment: Hibernate 3.1 plus Annotations extending EJB3 implementation
> Reporter: James Salt
> Attachments: nestedset.tar.gz
>
> Original Estimate: 3 weeks
> Remaining Estimate: 3 weeks
>
> An enhancement to allow entities to exist in a managed tree (DAG) structure, via the use of property annotations and entity annotations. With an extension to the HQL language to mimic the Oracle recusive query clause.
> This would be classically be useful for Bill of Material uses, or any tree like entity structure.
> I have implemented a homebrew approach using the 'adjacency list method' , and a post persist call back method to set the node path. Although I think a more full blown optimised algorithm would be the 'modified preorder tree traversal algorithm'.
> In the annotations world this could be implemented using an annotation like @Hierarchical to the entity, with a @Parent (mask for @ManyToOne) annotation on the parent field/parameter and @Children (mask for @OneToMany) annotation on the list of children entities.
> Then a postupdate method could be implemented for the entity type, that recalculates the tree meta data -i.e. parent, left and right.
> I believe this would be a valuable extension (useful for many common data models) to the hibernate core product that could be exposed through annotations as I have discussed and the hbm.xml.
> The users of such a system would be aware of the performance implications on insert/update/delete, but gain a massive performance gain on querying a tree data model.
>
--
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, 5 months
[Hibernate-JIRA] Created: (HSEARCH-417) SearchFactoryImpl close method is not called on application undeployment, leaving file handles open to indexes
by Hal Deadman (JIRA)
SearchFactoryImpl close method is not called on application undeployment, leaving file handles open to indexes
--------------------------------------------------------------------------------------------------------------
Key: HSEARCH-417
URL: http://opensource.atlassian.com/projects/hibernate/browse/HSEARCH-417
Project: Hibernate Search
Issue Type: Bug
Components: engine
Affects Versions: 3.1.1.GA
Environment: Hibernate 3.3.1.GA, Oracle 11g, Weblogic 10, Spring 2.5.6
Reporter: Hal Deadman
I have an application that does manual index builds periodically and when I undeploy the application I can still see all the file handles to the lucene indexes open (using sysinternals process explorer). The close method on SearchFactoryImpl is never called on application shutdown.
I was able to make a disposable spring bean that calls something like:
SearchFactory searchFactory = Search.getFullTextSession(session).getSearchFactory();
((SearchFactoryImpl ) searchFactory).close();
and that caused the file handles on the indexes to be closed.
I think the hibernate search objects need to clean up after themselves when the hibernate session factory is shut down. The close method is called in the cleanup method for FullTextIndexEventListener but that doesn't appear to get called with my configuration, possibly because the application does manual index builds?
--
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, 5 months
[Hibernate-JIRA] Commented: (HHH-1352) Session.setReadOnly(Object, boolean) fails for proxies
by Steve Ebersole (JIRA)
[ http://opensource.atlassian.com/projects/hibernate/browse/HHH-1352?page=c... ]
Steve Ebersole commented on HHH-1352:
-------------------------------------
Oops, the "patch" part of the comment comes from linked HHH-2501...
> Session.setReadOnly(Object, boolean) fails for proxies
> ------------------------------------------------------
>
> Key: HHH-1352
> URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-1352
> Project: Hibernate Core
> Issue Type: Bug
> Components: core
> Affects Versions: 3.1
> Environment: Hibernate 3.1, MySQL 5.0.15-nt
> Reporter: Stewart Cambridge
> Assignee: Steve Ebersole
> Priority: Minor
> Original Estimate: 1 day
> Remaining Estimate: 1 day
>
> Session.setReadOnly(Object, boolean) is broken. It throws a TransientObjectException with the message "Instance was not associated with the session" when the object is quite obvious associated with the current session, because we only just loaded it using Session.load(Class, Serializable)
> Here is a simple JUnit test, for an arbitrary entity:
> public void testReadOnly()
> throws Exception
> {
> User user = (User) session.load(User.class, new Long(7));
> System.out.println("\n=== " + user + " ===");
> session.setReadOnly(user, true);
> }
> This is the exception stack trace:
> org.hibernate.TransientObjectException: Instance was not associated with the session at org.hibernate.engine.StatefulPersistenceContext.setReadOnly(StatefulPersistenceContext.java:1167) at org.hibernate.impl.SessionImpl.setReadOnly(SessionImpl.java:1740) at
> test.persistence.HibernateObjectTest.testReadOnly(HibernateObjectTest.java:30) ....
--
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, 5 months