Hibernate anti-patterns and best practices – the server side java symposium

I was disappointed with this speaker’s previous session so I wasn’t sure whether to attend this one. I did like parts of this session better. It was interactive and presented alternate options. There was also a SQL/hsql puzzle to practice spotting errors. Similarly for java.

Transactional issues
Race condition if don’t have right transaction settings. Could solve with proper isolation level of serializable, but slows performance a lot. Repeatable read would not be ok because new row created in this example that not included in max so range query. Hibernate versioning also doesn’t help because on different table. Recommends reordering code so get Lock.UPGRADE first Note this is not a hibernate specific problem. The solution sounds like “for update” mode in Oracle. The speaker also noted an object should not be passing around internal state. Also not Hibernate specific, a query should be done in one step where possible.

other approaches:

  • track everything in Java, but then lose benefit of database
  • denormalize database
  • Use custom mappings with custom queries, laziness and order or where clause

Object oriented issues
Returning the raw list lets callers modify it, encapsulation matters, do not want inconsistent object state

To avoid

  • Write business methods before accessors
  • Hibernate can work with private, protected and package access
  • Date and Collections are the most likely causes of mutable internal state. Note that defensive copying requires retrieving all objects from thedatabase. Also Collections.unmodifiableList() is a problem because the dirty read check looks at the identity of objects.

Performance issues
There was some reuse in this section from the presenter’s other breakout.
Hibernate can be slow depending on usage. Having a getter return an unmodifiable list when cascade all is on, Hibernate deletes the whole collection and recreates if. The reason is that Hibernate sees the list as having a different identity. Thus can happen when calling get under certain conditions.

Automated detection
We got to hear content from the static analysis talk again. I didn’t like it any better this time because it is still vague.

Other things one could do wrong
Remember where clause criteria
Remember order of args in compareTo()

Conclusion – hibernate is hard, there will be a solution to make it easier one day

Rod Johnson in the cloud – the server side java symposium

Rod Johnson led off with a Dilbert cartoon about the cloud/platform – the pointy haired boss says “it’s like you are a technologist and philosopher all in one” in response to “blah blah blah cloud”.

Benefits of cloud

  • No reason to operate own data center because does not scale. Also noted the environmental impacts due to overprovisioning on small/medium data centers. Large companies will adopt onsite/internal clouds.
  • Compared computing to a utility and noted factories used to operate their own electricity. Really good analogy!

Perceived weakness for Java in the cloud

  • Perceived to be slow and startups look to Ruby and the like. This is a problem because these are the companies that are tomorrow’s leaders
  • Universal hosting not available like PHP

Strengths of Java in the cloud

  • Write once run anywhere
  • Java already in the enterprise
  • In actuality scales better than Ruby

Other Points

  • We think if the internet as free when we use it. However, there is a cost and the energy use is very high.
  • Rod Johnson considers flexibility to be a more important driver than cost. That way pay when need and not guessing up front if a startup will succeed. Compared to the Zipcar model. It costs more per mile but cheaper if don’t drive a lot. Another great analogy.
  • Simplicity, because large organizations have a lot of bureaucracy and provides a way to subvert that bureaucracy [some of that bureaucracy has a reason, accounting and security teams are not going to be happy with subverting things. However, an internal cloud provides benefits without subverting.]
  • Need architectural trade offs for economies of scale
  • If cloud is about business agility, need to be able apps fast which is why Rails shines. Notes the importance of being perceived as being able to start fast. [sounds like this is more valuable than maintenance]
  • It is more important to have one good option than a lot of medium options. Thinks Java community needs a cultural change to pick a stack. Showed how having two IDES of eclipse and intelij means good products and not a lot of poor choices. Interesting NetBeans was left off the list. rails helps because gives you less choices and saves time by encouraging consistency
  • The line between development and operations is blurring. No common tool chain organizational chaos. More self service in cloud because developers deploy

Spring’s thoughts

  • IaaS (infrastructure as a service) – vmware vcloud
  • PaaS (software as a service) – must abstract away OS, provide self service and be a productive programming model
  • Frameworks are key to portability – gave example that Spring isolates you from the app server [in other words if you deploy your container in your application, you don’t have to worry about the external container as much]. I liked the Ruby example better because Rails is. Framework that doesn’t replace the container.
  • Challenges: a lot more and complex data, adapt to RDBMS + NOSQL. Recognize what datastores need to be transactional. plugged Spring data project. Similarly for asynchronous data patterns
  • Visual builders are usually horrible because build uneditable code. Wavemaker is different because Spring owns it. I think there as another reason he tried to state but i didn’t catch it. Maybe it builds on roo?

Java’s phases

  • -2005 : make java work
  • 2005-2010: RIA, REST, higher productivity
  • 2010-?: beyond RDBMS, mobile/tablet, cloud, even higher productivity required

the end was all blatant advertising of spring’s tools.

Live from TSSJS – Lightweight J2EE with Adam

For my final TheServerSide Java Symposium breakout session for the day, I am attending “Lightweight Application Development with Java EE 6” presented by Adam Bien.  Adam’s talk is in part an attempt to bring former J2EE developers (myself included) back to the table who may have been driven off by previous, heavy-weight J2EE implementations, such as J2EE 1.4.

Adam spends most of his presentation actually building a simple Java EE 6 application on the fly, using Casino/Police/Mafia metaphor (since this conference is in Las Vegas).  I’ll try to capture the highlights in this blog, but the code itself says volumes about how simple to use Java EE 6 has become.  He develops in NetBeans IDe 6.9.1 with Glassfish as a web server, deploying everything as a WAR.

1.  Simplifying Code with Annotations
Java EE 6, like Java EE 5 before it, solves a lot of complexity and deployment issues through Java 1.5’s creation of annotations.  Adam shows a code example of a Stateless session bean is essentially just a POJO with the @Stateless annotation.  The only required import is “javax.ejb.Stateless” for the annotation to reference.

2.  Interceptors
Java EE 6 supports @Interceptors that redirect business methods for a better separation of POJOs and business logic.  Serves as a filter for business methods.

3.  Dependency Injection
The @Inject tag allows you create instances of related objects that live as long as the parent module.  Easy to create events and inject them into classes.

4.  Qualifiers
Adapted from Spring, helps control event ordering as far as which observer gets the message.  The annotation @Qualifier is used on the class level with a @Retention and @Target parameters.  The listener can then be updated to only listen to events of particular types or values.  Furthermore, they can be use for filtering on events which is useful for batch processing.

5.  Messaging
Java EE 6 supports @Asynchronous annotation for creating messaging handlers.

6.  Interfaces
Similar to previous versions of J2EE, you can define an interface for a session bean and use references to the interface instead of the concrete class.  Compiler throws an error if you try to inject an interface with no concrete implementation.

7.  J2EE and Spring
Adam recommends not mixing the two, and building entirely in Spring xor J2EE 5 or 6.  The features are very similar between the two and mixing them can be complicated.  One of the major new features of Java EE 6 is REST integration.

Conclusion
Adam did not present any slides, but built a quite impressive Java EE 6 application on the fly with very little code.  Everything he built deployed instanteously on his MacBook, and was accessible from the web browser right away.  Adam pointed out not all computers or operating systems build as quickly.

I asked Adam if he would be posting his code online since it was quite educational.  He said he will once he is back in Germany.