All entries for April 2006
April 27, 2006
Some more hibernate thingies
Writing about web page http://hibernate.org
Some more hibernate observations, although I haven't got time to prove via unit tests:
– if you specify an interface="" then the laziness is ignored; it is always lazy (not documented AFAICS)
– if you have final methods/class then regardless of access (field|property) you will get null values. This is because CGLIB cannot subclass/override final classes/methods (well known), but why doesn't hibernate throw an exception?
– if you specify non-lazy for a class, then the class is fully formed, even if it is using CGLIB with final classes/methods irrespective of access (property|field). I suspect in this case CGLIB isn't involved and hibernate is simply instantiating your implementation class and updating the fields via reflection.
– if you specify an outer join in the mapping, laziness will be ignored; it won't be lazy. This of course is intuitive; join makes no sense if it is not lazy.
When I have more time I will unit test all these combinations, but this is a reminder to me do so.
Will I ever understand hibernate completely :)
27 Apr 2006 12:42
| 
Tags: Hibernate
| 
Comments (4)
| 
Report a problem
Please wait - comments are loading
April 25, 2006
Hibernates bizarre interpretation of inverse ;)
Writing about web page hibernate.org
So my colleague asked me about the exact semantics of hibernate's "inverse" keyword which is surely the worst choice of word for a simple concept.
Essentially "inverse" indicates which end of a relationship should be ignored, so when persisting a parent who has a collection of children, should you ask the parent for its list of children, or ask the children who the parents are?
Why does this matter? Well if you are stupid then you might do something like:
Parent parentA = new Parent();
Parent parentB = new Parent();
Child child = new Child();
parentA.getChildren().add(child);
child.setParent(parentB);
how should hibernate persist this situation? For unidirectional one–to–many it is trivial; only one end of the relationship is modelled (there is only parent.addChild(), not child.getParent()), but when it is bidirectional (parent.getChild and child.getChildren) you need to indicate whether the one–to–many is inverse or not.
What does it mean to be inverse? It informs hibernate to ignore that end of the relationship. If the one–to–many was marked as inverse, hibernate would create a child–>parentB relationship (child.getParent). If the one–to–many was marked as non–inverse then a child–>parentA relationship would be created.
Or at least that is what you would think :) First moan is why use the word "inverse"? By setting it to true you are effectively telling hibernate to ignore it. Setting something to true to exclude something is reverse logic and is incredibly unintuitive. Maybe "owner" would be a better term?
The second moan is that hibernate isn't consistent. If the parent–>child is not inverse (i.e. parent.getChildren will be used to define the relationship) then you would expect calling child.setParent to have no effect. This is not the case. Calling child.setParent does create the relationship. If you end up with the idiotic case I proposed earlier, than hibernate will give precendece to the parent.getChildren (as it should), but to be consistent child.setParent(parentA) should not create the relationship.
It is such a simple concept, but so many people seem to struggle with it. I really don't think hibernates terminology is very helpful.
Simply put; if you set inverse=true on a one–to–many then child.getParent will be called, if inverse=false then parent.getChildren will be called.
Of course, good developers will not run into this problem because they will all ensure that parents have appropriate accessors (parent.addChild, parent.removeChild etc.) :)
The invertedness (?) of the relationship does have quite an impact on performance and schema design; if the one–to–many is not inverse (default) then everytime you create a child, hibernate will execute 2 statements, one to create the child, one to update the child with the foreign key of the parent. Foreign key constraints/not null constraints? hah, who needs those anyway :) Hibernate will also instantiate the collection everytime you add a child….not sure why. Setting inverse to true will fix both of these annoyances/downright ridiculous design decisions.
One last note; cascade and inverse are completely orthogonal. Cascade simply tells hibernate how to reach objects. If I set inverse=true on a one–to–many then hibernate will not use parent.getChildren to define the relationship. If I set cascade to save, or all then hibernate will call parent.getChildren to see if there are any new children. Setting inverse=true and calling child.setParent will have absolutely no effect because hibernate won't know about your new child :)
So summary:
– always provide parent.addChild which updates both ends of the relationship
– always set inverse to true on bidirectional one–to–many
– make sure you understand the difference between cascades and inverse ;)
P.S. Version 3.1.2 was used.
Code used for inverse relationship
<?xml version="1.0"?>
<!DOCTYPE hibernate–mapping PUBLIC
"–//Hibernate/Hibernate Mapping DTD 3.0//EN"
"http://hibernate.sourceforge.net/hibernate–mapping–3.0.dtd">
<hibernate–mapping>
<class name="uk.ac.warwick.Child" table="child">
<id name="id"
column="id"
type="java.lang.String"
unsaved–value="null">
<generator class="org.hibernate.id.UUIDHexGenerator"/>
</id>
<many–to–one name="parent"
class="uk.ac.warwick.Parent"
column="parent_id"/>
</class>
</hibernate–mapping>
<?xml version="1.0"?>
<!DOCTYPE hibernate–mapping PUBLIC
"–//Hibernate/Hibernate Mapping DTD 3.0//EN"
"http://hibernate.sourceforge.net/hibernate–mapping–3.0.dtd">
<hibernate–mapping>
<class name="uk.ac.warwick.Parent" table="parent">
<id name="id"
column="id"
type="java.lang.String"
unsaved–value="null">
<generator class="org.hibernate.id.UUIDHexGenerator"/>
</id>
<bag name="children" inverse="true" cascade="save–update">
<key column="parent_id"/>
<one–to–many class="uk.ac.warwick.Child"/>
</bag>
</class>
</hibernate–mapping>
package uk.ac.warwick.inverse;
import junit.framework.TestCase;
import org.hibernate.Session;
import org.hibernate.SessionFactory;
import org.hibernate.cfg.Configuration;
import uk.ac.warwick.Child;
import uk.ac.warwick.Parent;
public final class TestRelationships extends TestCase {
public void testChildrenOfParentAreIgnored() {
Configuration config = new Configuration();
config.addResource("uk/ac/warwick/inverse/Child.hbm.xml");
config.addResource("uk/ac/warwick/inverse/Parent.hbm.xml");
config.setProperty("hibernate.dialect", "org.hibernate.dialect.HSQLDialect");
config.setProperty("hibernate.connection.driver_class", "org.hsqldb.jdbcDriver");
config.setProperty("hibernate.hbm2ddl.auto", "create–drop");
config.setProperty("hibernate.show_sql", "true");
config.setProperty("hibernate.connection.url", "jdbc:hsqldb:.");
config.setProperty("hibernate.connection.username", "sa");
SessionFactory factory = config.buildSessionFactory();
Session session = factory.openSession();
Parent parentA = new Parent();
session.save(parentA);
session.flush();
/**
* Because parent–>child is inverse, adding the child to the parent
* will not associate it with the parent.
*
* Cascade will save it though.
*/
Child childA = new Child();
parentA.getChildren().add(childA);
session.save(parentA);
session.flush();
session.evict(childA);
assertEquals("cascade works so child should be saved",
1,
session.createCriteria(Child.class).list().size());
childA = (Child) session.load(Child.class, childA.getId());
assertNull("childAs parent should not be set!",
childA.getParent());
session.evict(parentA);
parentA = (Parent) session.load(Parent.class, parentA.getId());
assertTrue("but it shouldnt update the children of parentA",
parentA.getChildren().isEmpty());
childA.setParent(parentA);
session.save(childA);
session.flush();
/**
* Because child–>parent is not inverse, setting the parent
* will create the association
*/
childA.setParent(parentA);
session.save(childA);
session.flush();
session.evict(childA);
childA = (Child) session.load(Child.class, childA.getId());
assertEquals("childAs parent should now be set!",
parentA,
childA.getParent());
session.evict(parentA);
parentA = (Parent) session.load(Parent.class, parentA.getId());
assertFalse("and parentA should have children",
parentA.getChildren().isEmpty());
}
}
Code used for non inverse relationship
<?xml version="1.0"?>
<!DOCTYPE hibernate–mapping PUBLIC
"–//Hibernate/Hibernate Mapping DTD 3.0//EN"
"http://hibernate.sourceforge.net/hibernate–mapping–3.0.dtd">
<hibernate–mapping>
<class name="uk.ac.warwick.Child" table="child">
<id name="id"
column="id"
type="java.lang.String"
unsaved–value="null">
<generator class="org.hibernate.id.UUIDHexGenerator"/>
</id>
<many–to–one name="parent"
class="uk.ac.warwick.Parent"
column="parent_id"/>
</class>
</hibernate–mapping>
<?xml version="1.0"?>
<!DOCTYPE hibernate–mapping PUBLIC
"–//Hibernate/Hibernate Mapping DTD 3.0//EN"
"http://hibernate.sourceforge.net/hibernate–mapping–3.0.dtd">
<hibernate–mapping>
<class name="uk.ac.warwick.Parent" table="parent">
<id name="id"
column="id"
type="java.lang.String"
unsaved–value="null">
<generator class="org.hibernate.id.UUIDHexGenerator"/>
</id>
<bag name="children" inverse="false" cascade="save–update">
<key column="parent_id"/>
<one–to–many class="uk.ac.warwick.Child"/>
</bag>
</class>
</hibernate–mapping>
package uk.ac.warwick.non_inverse;
import junit.framework.TestCase;
import org.hibernate.Session;
import org.hibernate.SessionFactory;
import org.hibernate.cfg.Configuration;
import uk.ac.warwick.Child;
import uk.ac.warwick.Parent;
public final class TestRelationships extends TestCase {
public void testParentOfChildrenAreIgnored() {
Configuration config = new Configuration();
config.addResource("uk/ac/warwick/non_inverse/Child.hbm.xml");
config.addResource("uk/ac/warwick/non_inverse/Parent.hbm.xml");
config.setProperty("hibernate.dialect", "org.hibernate.dialect.HSQLDialect");
config.setProperty("hibernate.connection.driver_class", "org.hsqldb.jdbcDriver");
config.setProperty("hibernate.hbm2ddl.auto", "create–drop");
config.setProperty("hibernate.show_sql", "true");
config.setProperty("hibernate.connection.url", "jdbc:hsqldb:.");
config.setProperty("hibernate.connection.username", "sa");
SessionFactory factory = config.buildSessionFactory();
Session session = factory.openSession();
Parent parentA = new Parent();
session.save(parentA);
session.flush();
/**
* Even though child–>parent is inverse, setting the parent
* will associate it with the parent.
*/
Child childA = new Child();
childA.setParent(parentA);
session.save(childA);
session.flush();
session.evict(childA);
assertEquals("cascade works so child should be saved",
1,
session.createCriteria(Child.class).list().size());
childA = (Child) session.load(Child.class, childA.getId());
assertNotNull("childAs parent will be set!",
childA.getParent());
session.evict(parentA);
parentA = (Parent) session.load(Parent.class, parentA.getId());
assertFalse("and it will update the children of parentA",
parentA.getChildren().isEmpty());
}
}
25 Apr 2006 15:49
| Tags: Hibernate Inverse Relationship
| Comments (18)
| Report a problem
April 24, 2006
Exciting new Mustang features (Java SE 6)
Writing about web page http://java.sun.com/javase/6/download.jsp
So I just noticed that version 6 (beta) of the J2SE is out and decided to have a browser through the release notes: link.
A couple of things caught my eye:
link (Compiler API)
I imagine this will drastically improve IDE internal compile/code completion functionality no end. I can also envisage some scenarios where this would be useful from in an application; maybe an alternative to weird and wonderful aspects aspects ;)
link (Scripting support)
This I am sure will cause a stir, and everybody will start writing "frameworks" which allow rules to be written in a scripting language….only to find that actually all they have done is lost the richness and strong typing of Java and haven't really gained anything.
I am not saying Scripting is a bad thing; only that it has it's place…. Thats my opinion anyway :)
link (Common annotations)
Well this can only be a good thing really.
link (Lightweight HTTP server)
If this isn't the most ridiculous waste of time ever …. wheel … re-invent (probably badly) ….
link (Classpath wildcards)
About time. I cannot believe it has taken so long for this to come into play.
It looks very promising. There are also a lot of performance enhancements which could be promising.
Let's wait and see.
24 Apr 2006 13:25
| Comments (0)
| Report a problem
April 20, 2006
Crappy java.sql.Timestamp pretending to be java.util.Date
So I started getting ClassCastExceptions when comparing two java.util.Dates. Tracking it down, I realised (and in fact the stack trace told me) that one of the java.util.Dates was actually a java.sql.Timestamp. So looking at the code, I was a bit surprised to realise that I was actually casting the objects to java.util.Date….which is valid because java.sql.Timestamp extends java.util.Date.
So why doesn't it work, and whose fault is it?
On the face of it, it would appear java.util.Timestamp is at fault because it is a java.util.Date and should therefore be able to be used in place of a java.util.Date; quite a fundamental OO rule (substitution). But then thinking a bit more, I realised it isn't quite so clear cut... The substitution rule states that you must be able to use any subclass in place of it's parent, but it doesn't state that the sub class must behave exactly like it's parent...which is obvious when you think about it. If this wasn't the case, you would never be allowed to change the behaviour of any of the methods. Arguably, you should never make the behaviour inconsistent with the intention of the super classes' method.
In otherwords, java.util.Date.compareTo(java.util.Timestamp) must work, but there is no guarantee that java.util.Timestamp.compareTo(java.util.Date) needs to work..
And in fact, it was java.sql.Timestamp.compareTo(java.util.Date) was throwing the exception.
So it seems java.sql.Timestamp is technically correct, even if it isn't very friendly :(
Still think it is wrong, but not sure it is technically wrong…..
20 Apr 2006 13:11
| Tags: Crappy Date Java Timestamp
| Comments (1)
| Report a problem
April 18, 2006
Testing configuration in spring
Useful tips for unit testing the configuration in spring:
If you have lots of references like "/WEB-INF/xyz" then Spring will convert these FieSystemResources. This is fine, if your root directory contains "/WEB-INF/", but it probably doesn't. Our project structure has "/WEB-INF" living underneath "/war". To fix this simply provide your own FileSystemResourceLoader:
FileSystemResourceLoader fileSystemResourceLoader = new FileSystemResourceLoader() {
protected Resource getResourceByPath(String path) {
path = "/war" + path;
return super.getResourceByPath(path);
}
};
Secondly, if you have an applicationContext and a number of -servlet and you are not explicitly listing the -servlet.xml in the ContextLoader then spring creates the parent applicationContext.xml and then creates child applicationContexts for each -servlet. You need to mirror this hierarchy, otherwise you may end up running into namespace clashes:
GenericWebApplicationContext parentCtx = new GenericWebApplicationContext();
parentCtx.setServletContext(new MockServletContext());
/**
* Files are referenced (e.g.) "/WEB-INF" however that won't resolve during this test
* so correct the path.
*/
FileSystemResourceLoader fileSystemResourceLoader = new FileSystemResourceLoader() {
protected Resource getResourceByPath(String path) {
path = "/war" + path;
return super.getResourceByPath(path);
}
};
FileSystemResourceLoader loader = fileSystemResourceLoader;
parentCtx.setResourceLoader(loader);
configureSystemProperties();
XmlBeanDefinitionReader parentXmlReader = new XmlBeanDefinitionReader(parentCtx);
/**
* Cannot use classpath because crappy Eclipse (or my crappy knowledge
* of eclipse ;)) won't let you have a folder as a classpath and show
* in package explorer. Besides which web-inf/classes is already on the
* classpath (for Chris + tomcat) and eclipse definately won't allow
* nested classpaths (i.e. /web-inf)
*/
String[] contextFiles = {
"applicationContext.xml",
"sitebuilderAdmin-servlet.xml",
"sitebuilderApi-servlet.xml",
"sitebuilderEdit-servlet.xml",
"sitebuilderError-servlet.xml",
"sitebuilderRender-servlet.xml",
"sitebuilderUser-servlet.xml"
};
/**
* Must load each context into it's own file to prevent name space clashes.
*/
for (String contextFile: contextFiles) {
GenericWebApplicationContext childCtx = new GenericWebApplicationContext();
childCtx.setServletContext(new MockServletContext());
childCtx.setParent(parentCtx);
childCtx.setResourceLoader(loader);
XmlBeanDefinitionReader childXmlReader = new XmlBeanDefinitionReader(parentCtx);
childXmlReader.loadBeanDefinitions(new FileSystemResource(FILE_PREFIX + contextFile));
childCtx.refresh();
}
And finally; move all external beans (JNDI, DataSource etc.) out of the applicationContext and into their own contexts. I had already done this, and the applicationContext imported them as it is good practice to fragment large XML files into smaller atomic units. Rather than applicationContext importing them directly, wire them up in the contextLoader:
contextConfigLocation
/WEB-INF/applicationContext.xml, /WEB-INF/hibernate-context.xml, /WEB-INF/tiles-context.xml
The last tip is rewrite crappy crappy tilesConfigurer! The problem is that the tilesConfigurer doesn't expect a number of resources, it expects a single comma seperated String :( This means that if you specify "/WEB-INF/" then everything will break because the directory doesn't exist (it is /war/WEB-INF).
The whole thing would have been much simpler if eclipse allowed you to specify a folder as being on the classpath and showed it in package explorer. At the moment as soon as a folder is marked as being on the class path it is hidden from the explorer.
HTH
18 Apr 2006 15:59
| Comments (0)
| Report a problem
Interesting article about blogs
Writing about web page http://elliottback.com.nyud.net:8080/wp/?p=1351
Nice article summarising the top 10 blogs (from a design point of view).
18 Apr 2006 10:11
| Tags: Blogs Design
| Comments (0)
| Report a problem
April 15, 2006
Performance of Spring CGLIB and JDK proxies
So I noticed a couple of questions popping up on the Spring forums asking about the cost of using AOP in Spring. This is really a question of how expensive CGLIB or JDK proxies are.
Since I had no real idea (there are lots of "not than expensive" comments around) I decided to write a little test.
Essentially I construct X instances of a class, X instances of a CGLIB proxy of that class (cglib sub classes the target class) and X instances of a JDK proxy, and then called the same method on each instance and measured the time. Hardly conclusive, but enough to give an idea.
I assumed the impact was minimal; when X is 10000:
Unproxied: 926654(ns) 9(ms) cglib: 23986289(ns) 239(ms) Proxy: 70206129(ns) 702(ms)
I expected some over head, but notwhere near that much….. I was also suprised that CGLIB was almost 3 times quicker than JDK proxies (JDK1.5.0_06 on WinXP SP2).
It is still a long way away from being the bottleneck in any system I am likely to write, but good to know :)
I expect AspectJ style weaving is probably a lot more efficient because (IIUI) it modified the byte code directly. Of course, there is an overhead of the modification, but that is a one off…. But I may be so completely wrong :)
Code:
public class MyClassImpl implements MyClass {
public void doSomething() {
}
}
public interface MyClass {
void doSomething();
}
import junit.framework.TestCase;
import org.springframework.aop.framework.ProxyFactoryBean;
public final class ProxyTest extends TestCase {
public void testPerformance() {
int numberToExecute = 10000;
MyClass[] classes = new MyClass[numberToExecute];
for (int i = 0; i< numberToExecute; i++) {
classes[i] = new MyClassImpl();
}
MyClass[] cglibProxyClasses = new MyClassImpl[numberToExecute];
for (int i = 0; i< numberToExecute; i++) {
ProxyFactoryBean factoryBean = new ProxyFactoryBean();
factoryBean.setProxyTargetClass(true);
factoryBean.setTarget(classes[i]);
cglibProxyClasses[i] = (MyClass) factoryBean.getObject();
}
MyClass[] proxyClasses = new MyClass[numberToExecute];
for (int i = 0; i< numberToExecute; i++) {
ProxyFactoryBean factoryBean = new ProxyFactoryBean();
factoryBean.setProxyTargetClass(false);
factoryBean.setInterfaces(new Class[] {MyClass.class });
factoryBean.setTarget(classes[i]);
proxyClasses[i] = (MyClass) factoryBean.getObject();
}
long unproxyExecution = executeClasses(numberToExecute, classes);
displayResults("Unproxied", unproxyExecution);
long cglibExecution = executeClasses(numberToExecute, cglibProxyClasses);
displayResults("cglib", cglibExecution);
long proxyExecution = executeClasses(numberToExecute, proxyClasses);
displayResults("Proxy", proxyExecution);
}
private void displayResults(String label, long unproxyExecution) {
System.out.println(label + ": " + unproxyExecution + "(ns) " + (unproxyExecution / 100000) + "(ms)");
}
private long executeClasses(int numberToExecute, MyClass[] classes) {
long start = System.nanoTime();
for (int i = 0; i< numberToExecute; i++) {
classes[i].doSomething();
}
long end = System.nanoTime();
long execution = end – start;
return execution;
}
}
15 Apr 2006 11:17
| Tags: Cglib Proxy Spring
| Comments (1)
| Report a problem
April 12, 2006
Yeah! Hibernate doesn't require cglib
Writing about web page http://hibernate.org/250.html#A37
There has been a long running problem with the combination of hibernate, CGLIB and an application server resulting in memory leaks. There seems to be some debate about whether it is purely a fault of CGLIB or not, and I don't know enough (or care) to make a guess. I do know that CGLIB is a fantastic and extremely powerful library :)
The problem manifests itself in only being able to deploy a handful of times on before running out of heap space.
Anyways, it appears Hibernate 3.2 is no longer dependant upon CGLIB. Yeah :)
Given that we do not use CGLIB in spring (we use JDK proxies) this might just mean we can deploy more than 5 times :) Very useful when developing ;)
12 Apr 2006 10:52
| Tags: Cglib Hibernate
| Comments (0)
| Report a problem
April 05, 2006
Crappy crappy SortedSet!!! Why oh why???
Writing about web page http://java.sun.com/j2se/1.4.2/docs/api/java/util/SortedSet.html
So, what is the contract for a set?:
A collection that contains no duplicate elements. More formally, sets contain no pair of elements e1 and e2 such that e1.equals(e2), and at most one null element. As implied by its name, this interface models the mathematical set abstraction.
So what is the contract for a SortedSet?:
A set that further guarantees that its iterator will traverse the set in ascending element order, sorted according to the natural ordering of its elements (see Comparable), or by a Comparator provided at sorted set creation time. Several additional operations are provided to take advantage of the ordering. (This interface is the set analogue of SortedMap.)
Simple, sets do not support duplicates, SortedSets add an order? Right? Yes, but SortedSets also utterly break the contract of Sets (or at least add a stupid restriction); it completely ignores equals and uses compareTo instead! Why!. The java doc kinda hints at this:
Note that the ordering maintained by a sorted set (whether or not an explicit comparator is provided) must be consistent with equals if the sorted set is to correctly implement the Set interface. (See the Comparable interface or Comparator interface for a precise definition of consistent with equals.) This is so because the Set interface is defined in terms of the equals operation, but a sorted set performs all element comparisons using its compareTo (or compare) method, so two elements that are deemed equal by this method are, from the standpoint of the sorted set, equal. The behavior of a sorted set is well-defined even if its ordering is inconsistent with equals; it just fails to obey the general contract of the Set interface.
I took this to mean that if the two objects are equals, then compareTo must return 0, but not, it means if compareTo returns 0 then a SortedSet treats them as equal, even if equal returns false!!!!
Code to prove it:
class TestClass implements Comparable {
private final Integer id;
private final String s;
public TestClass(final Integer id, final String s) {
this.id = id;
this.s = s;
}
public int compareTo(final Object o) {
if (equals(o)) {
return 0;
}
return ((TestClass)o).s.compareTo(s);
}
public boolean equals(final Object o) {
return ((TestClass)o).id.equals(id);
}
}
public void testTheProblem() {
TestClass firstTestClass = new TestClass(1, "same string");
TestClass secondTestClass = new TestClass(2, "same string");
assertFalse("equality", firstTestClass.equals(secondTestClass));
assertTrue("comparison", firstTestClass.compareTo(secondTestClass) == 0);
SortedSet testClasses = new TreeSet();
assertTrue("adding first item", testClasses.add(firstTestClass));
// this fails!!!
assertTrue("adding second item", testClasses.add(secondTestClass));
}
05 Apr 2006 12:12
| Comments (7)
| Report a problem
Loading…