Posted by Kris Geusebroek in the late evening: February 14th, 2011
At our project the focus is at making the application stable and controllable. So instead of building cool new features
we are spending our time making sure the application is able to run stable in the production environment.
After the first few issues the so called ‘Transaction timeout’ issue raised it’s ugly head.
Every now and then the application threw an exception due to a transaction timeout.
This was very strange since the timeout was set to 30 seconds and the complete processing of the whole
application was done in less than 2 seconds (spread over more than 1 transaction).
(more…)
Posted by Andrew Phillips mid-morning: November 9th, 2009
In the careers of most Spring/Hibernate developers I know, there sooner or later comes a point of no escape…they have to write a Hibernate user type. The first one is usually of the copy’n'paste variety, and by and large works perfectly well.
But when things are no longer going quite as expected – Hibernate is ignoring changes to items managed by the user type, for instance – it often becomes apparent that one doesn’t sufficiently understand how these user type thingies are supposed to work. At least, that’s what happened to me.
In this post, we’ll be dissecting the Hibernate UserType interface, explaining the relationships between the various methods, and developing a set of base user types that capture common use cases. (more…)
Posted by Maarten Winkels in the early morning: August 28th, 2009
For my current project we use Kettle to process data from a number of sources and store it in a shared database. Kettle has great support for parsing data from a variety of sources, transforming it and writing it to a variety of destinations. One problem that often arises when inserting data in a relational database is the need for a syntactic, unique key that will be generated when a new row is inserted and later in the process used for other rows that refer the primary row. There are many solutions for this problem, both in the RDBMS and in the Java space. This blog reports on a search through several code bases to come up with a good solution in kettle which, unfortunately, still evades me.
(more…)
Posted by Vincent Partington in the early evening: June 21st, 2009
Last week I discussed the relative merits of field access versus property access in the ongoing JPA implementation patterns blog series. This week I will dwell on the choices offered when mapping inheritance hierarchies in JPA.
JPA provides three ways to map Java inheritance hierarchies to database tables:
- InheritanceType.SINGLE_TABLE – The whole inheritance hierarchy is mapped to one table. An object is stored in exactly one row in that table and the discriminator value stored in the discriminator column specifies the type of the object. Any fields not used in a superclass or a different branch of the hierarchy are set to NULL. This is the default inheritance mapping strategy used by JPA.
- InheritanceType.TABLE_PER_CLASS – Every concrete entity class in the hierarchy is mapped to a separate table. An object is stored in exactly one row in the specific table for its type. That specific table contains column for all the fields of the concrete class, including any inherited fields. This means that siblings in an inheritance hierarchy will each have their own copy of the fields they inherit from their superclass. A UNION of the separate tables is performed when querying on the superclass.
- InheritanceType.JOINED – Every class in the hierarchy is represented as a separate table, causing no field duplication to occur. An object is stored spread out over multiple tables; one row in each of the tables that make up its class inheritance hierarchy. The is-a relation between a subclass and its superclass is represented as a foreign key relation from the “subtable” to the “supertable” and the mapped tables are JOINed to load all the fields of an entity.
A nice comparison of the JPA inheritance mapping options with pictures, and including a description of the @MappedSuperclass option, can be found in the DataNucleus documentation.
Now the interesting question is: which method works best in what circumstances?
(more…)
Posted by Vincent Partington around lunchtime: June 13th, 2009
Last week my colleague Albert Sikkema blogged about using UUIDs as primary keys. Interesting stuff, thanks again, Albert! This week I will continue the JPA implementation patterns series by discussing the relative merits of field access vs. property access.
The JPA specification allows two ways for the persistence provider to access the persistent state of an entity. The persistence provider can either invoke JavaBeans style property accessors (getters and setters) or access the instance fields of the entity directly. Which method is used depends on whether you have annotated the properties or the fields of an entity.
(more…)
Posted by Albert Sikkema at around evening time: June 3rd, 2009
Continuing Vincent Partington‘s blog series about JPA implementation patterns, I would like to add the following
The default way in JPA for primary keys is to use the @GeneratedValue annotation with the strategy attribute set to one of AUTO, IDENTITY, SEQUENCE, or TABLE. You pick the most appropriate strategy for your situation and that’s it.
But you can also choose to generate the primary key yourself.
(more…)
Posted by Vincent Partington at around evening time: May 25th, 2009
Two weeks ago I blogged about the use of the Service Facade and Data Transfer Object pattern in JPA application architecture. This week I will move from the high level perspective and discuss an interesting interaction I discovered between the way bidirectional associations are managed and lazy loading. So let’s roll up our sleeves and get dirty in this next installation of the JPA implementation patterns series. 
This blog assumes that you are familiar with the Order/OrderLine example I introduced in the first two blogs of this series. If you are not, please review the example.
Consider the following code:
OrderLine orderLineToRemove = orderLineDao.findById(30);
orderLineToRemove.setOrder(null);
The intention of this code is to unassociate the OrderLine with the Order it was previously associated with. You might imagine doing this prior to removing the OrderLine object (although you can also use the @PreRemove annotation to have this done automatically) or when you want to attach the OrderLine to a different Order entity.
If you run this code you will find that the following entities will be loaded:
- The OrderLine with id 30.
- The Order associated with the OrderLine. This happens because the OrderLine.setOrder method invokes the Order.internalRemoveOrderLine method to remove the OrderLine from its parent Order object.
- All the other OrderLines that are associated with that Order! The Order.orderLines set is loaded when the OrderLine object with id 30 is removed from it.
Posted by Vincent Partington at around evening time: April 27th, 2009
In the previous three blogs about JPA implementation patterns, I covered the basis operations of saving entities, retrieving entities, and removing entities. In this blog I will continue along a different angle, exploring the subject of how entities are lazily loaded and how that affects your application.
Anybody that has been working with Hibernate for a while has probably seen a LazyInitializationException or two, usually followed by a message such as “failed to lazily initialize a collection of role: com.xebia.jpaip.order.Order.orderLines, no session or session was closed” or “could not initialize proxy – no Session”. Even though these message may baffle new users of Hibernate, they are a lot better than the NullPointerExceptions OpenJPA gives you in these cases (at least when using runtime bytecode enhancement).
To use JPA to its full potential it is imperative to understand how lazy loading works, as it allows you to model your complete database with all its relations without loading that whole database as soon as you access just one entity.
(more…)
Posted by Vincent Partington in the early morning: April 9th, 2009
For the last few weeks I have been covering the implementation patterns I discovered while writing JPA applications. The last two blogs covered saving entities and retrieving entities. But when you’re really through with your entities, I guess you’d want to remove them too. So that is the subject of this blog.
Just like retrieving an entity, removing an entity is pretty simple. In fact it’s all you need to do is pass the entity to the EntityManager.remove method to remove the entity from the database when the transaction is committed (Of course you’d actually invoke a remove method on your DAO which in turn invokes EntityManager.remote). That’s all there is to it. Usually. Because when you’re using associations (be they bidirectional or not) things get more interesting.
(more…)
Posted by Anurag Shrivastava terribly early in the morning: April 7th, 2009
San Francisco 31 March – 3 April: Web 2.0 Expo brought together people with diverse professional backgrounds, having interest in Web 2.0, at Mascone Centre in San Francisco. San Francisco Bay Area, also known as Silicon Valley boasts of high concentration of information technology companies of all sizes ranging from biggies like Intel Corporation to numerous start ups trying to make it big.
(more…)