JEE 6 patterns – the server side java symposium

As of Websphere 8, all major app servers support J EE 6 except one that I hadn’t heard of. Adam Bien got a number of jabs in at Rod Johnson’s comment that NetBeans isn’t prevalent.

Many patterns are gone from earlier versions of JEE including this list. Amazing how much content was discussed on one slide.

  • most interfaces – Adam mentioned another valid use of interfaces – reuse. Also noted the IXXX or XXXImpl are signs that the interface isn’t needed.
  • DAOs – should be able to state the reason if have. To avoid duplication have a service with a business name. for example OrderSearchService
  • DTOs – duplication across layers. And if you use a mapping framework like bean utils, you aren’t really decoupling. It is useful to do create a DTO when you don’t have control over the underlying object. Similar reasoning to interfaces. A good metric is whether every layer is affected for a feature request
  • ServiceLocator, Factory – use injection
  • Business Delegate – just delegates to ejb, for handling exceptions
  • Session Facade – needed to wrap CMP because didn’t work well
  • Value Object Assemblers – can just create aggregate object
  • Service Activator – asynchronous support now built in with annotation or CDI events if want ti decouple
  • Publish Subscribe with JMS – for local delivery, use CDI events instead
  • Mandatory XML configuration – Repeating the whole package name in xml so hard to refactor. Adam sounds like he favors minimal XML. I asked what belongs in XML and the answer was passwords/ips. [I don’t think he meant passwords]. He did say anything that could change often.

Other Notes

  • Keep the war as small as possible to speed up deployment. try to keep infrastructure jars out of war manage versions of jars by deploying to separate tomcat if have to use third party jars. Adam doesn’t use third party jars unless absolutely necessary
  • go for convention over configuration
  • ECB – entity (jpa) control (optional cdi bean) boundary (stateless entry point decorated by aspects), way to model a component
  • see anti if campaign website for the lack of OO in JEE

I missed a bit of this presentation even though it was really good because I was getting ready for mine.

Extreme performance in database – the server side java symposium

I wasn’t sure whether to blog about this session. Scott feels i haven’t written enough here at the Server Side Java Symposium so i decided to go for it :). Unfortunately, he didn’t say anything I could write without doing a free press release. So here’s a really short summary.

The one slide is an ad. Globalsdb.org has a free database that will be launched March 24th. Every month there will be a contest to prove what can be done on the platform.

One phrase jumped out: “what can you do with the right incentive”. And that they recognize press and money are both incentives.

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