techno.blog("Dion")

What a roller-coaster game this is.

- First we go up 1-0 through a great Michael Owen goal
- Then we do the usual, and sit back and the pressure comes on us
- Rooney gets injured and has to go off
- They score to even the game 1-1 in the last 7 minutes
- We end up with extra time
- Then score to go up 2-1, and it looks over
- Lampard sneaks one in to bring it 2-2
- Penalties
- Beckham misses
- They miss
- Sudden death penalties after we are even on 4-4 after 5
- WE LOSE! :(

I just wanted to announce that I am not offering any Gmail invitations.

If you post a comment, or a track back, I will not give you an invitation, but may wish you luck in getting one from someone else (or may not).

Thanks.

Debu Panda has written an article on Using a JMS Provider with MDBs via the J2EE Connector Architecture.

You often find that once a technology is fairly mature, changes in version don’t get as much attention, unless they are a rewrite like EJB 3 ;)

The latest versions of J2EE Connector Architecture, JMS, and MDBs make the technologies a lot nicer to use. It is great that we can write MDBs that use messages that are not JMS messages.

I also like the fact that with JMS 1.1 we don’t have the two parralel object trees of Queues and Topics. It is a lot nicer that you can use the MessageProducer/MessageConsumer which works with both point-to-point and pub/sub. Now I don’t have to tweak my client code if I change the publishing model.

A nice article…. *go to page 2 to get to the real meat*.

I am really looking forward to this years JavaOne. It is for the sessions, or the news? Not necessarily ;)

I am looking forward to meeting with fellow technologists and friends. As always, I am also happy to meet up with new people in the flesh that I have only had the pleasure to talk to via the ether.

I hope to meet you all next week.

I am going to the JavaOne Blogger Meetup Next Monday

Scott Ferguson has written a simple blog entry that compares JDO, EJB/CMP, Hibernate and Amber.

He has simple Pro’s and Con’s for the various solutions and manages to keep it 100% technical. He stays away from the politics. Nicely done.

Regarding some of his comments:

• I don’t want my OR mapper to be passing around java.sql.ResultSets. I want to work with objects!
• JDO-QL may not be perfect, but in JDO 2 you can use other languages, such as SQL itself (but anything that you want/the vendor allows!)

I enjoyed Charles’ post on I Love Postgres, especially since TheServerSide.com runs on Postgres.

We are big fans of EXPLAIN, however we do not have a fulltime DBA. Maybe it is just my perspective, but the DBA role seems to have dwindled slightly in the companies that I have been at. Large companies definitely still have them, but they seem to ask more of fewer of them. Small companies try hard to get by without them, and ask developers / sysadmins to wear that hat.

Maybe we aren’t paying as much attention to the database as we should be as you can “get by” without (in a passive way… until something breaks).

I have worked with some amazing DBAs in the past, and know what they bring to the table. They can do fantastic things, which go far beyond tweaking performance. Some of the data designs I have seen in the past were so elegant I really didn’t want to screw them up with my object model ;)

Now, I raise my glass, to the wizard DBA.

Bob has written about refactoring dynaop Factories using dynaop.

It definitely feels that many of the patterns that are out there, are hacks to get around a lack in the particular language/system that you are working with.

Factories are definitely an annoyance for me. Having to create factories for various types is just a pain, especially when they are often trivial implementations.

I really like how I can use introductions/mixins with certain languages. I then really like being able to:

• Setup an interface
• Have the interface contain an introduction which can handle returning an implementation of that interface

I have been quiet on the ole blog over the last few days as I am in the middle of a move from Boston across the country.

It is always a pleasure moving isn’t it? We did it ourselves. Packed the truck, and drove the truck.

The drive was uneventful, but was made better due to the following:

• iPod w/ FM tuner: We were spared the routine of hunting through stations telling you about the pork belly prices, as we were able to play DJ with the iPod. The truck was obviously not going to have a CD player or anything, but FM it did had… and we were saved.
• Amish: One of the funniest sights that I had was in Indiana. I was at a service stop, and saw an Amish family (in full garb) rushing to a video game area of the mini-mall. Not only was it comedy to see these people enjoying the games so much (I thought they were all about dissing “new fangled gismos”), but they also chose to play a DRIVING game. The last thing that I would want to do after a day on the road is play a game that has you… DRIVING!

I am glad to say that we arrived safely, with car in tow, and look forward to moving into our new house tomorrow morning!

Then, after a quick week I will be flying out to JavaOne. I hope to see anyone there!

I really like the “help” that Spring gives to the tools that you use every day. Some of the items are small things, some are larger, but they all take off some of the burden of development.

I really like the *Template code (Jdbc, Jdo, Hibernate, etc) that wraps the data tier. Today I really liked seeing the hard work that Juergen put into the JdoTemplate/subsystems.

I have projects using Spring/JDO, so thanks to Juergen’s efforts, he has helped make them a success.

Hi everybody,

I’ve significantly refined Spring’s JDO support, to get it closer to the level of our Hibernate support:

* Standard JDOException -> DataAccessException conversion in PersistenceManagerFactoryUtils is more sophisticated now, properly detecting JDOObjectNotFoundException, JDOOptimisticVerificationException and JDODataStoreException. For more sophisticated, implementation-specific exception translation (for example, detecing data integrity violation), there’s still the need to implement JdoDialect’s “translateException” method.

* JdoDialect has a “beginTransaction” method now, passing in a Spring TransactionDefinition. Implementations can apply the isolation level and/or transaction timeout before they call javax.jdo.Transaction’s “begin”. Spring’s JdoTransactionManager delegates to this method; DefaultJdoDialect does nothing special here, but custom JdoDialect implementations can override this. (Note that both HibernateTransactionManager and DataSourceTransactionManager support isolation levels and timeouts.)

* JdoDialect has a “releaseJdbcConnection” method now, for JDO implementations that expect the JDBC Connection handle that they returned on “getJdbcConnection” to be explictly released. (If explicit closing is not necessary, this method can be empty.) Spring’s JdoTransactionManager properly invokes “releaseJdbcConnection” on transaction cleanup. Note that “getJdbcConnection” returns a ConnectionHandle, to be passed into “releaseJdbcConnection”, which allows for a wider range of release strategies.

* JdoTemplate features a number of convenience methods now, for typical data access operations (load, save, delete, find). Those methods are defined in the new JdoOperations interface; this is analagous to HibernateTemplate and HibernateOperations. The names of the methods follow JDO naming conventions, to look natural to people that are used to the PersistenceManager API (and to imply the same semantics). For more sophisticated querying needs, you still need to implement a JdoCallback and work with the JDO Query API.

* The jdo.support package provides OpenPersistenceManagerInViewInterceptor (for Spring’s web MVC framework) and OpenPersistenceManagerInViewFilter (Servlet 2.3 Filter) implementations now, for keeping a PersistenceManager open during the entire request processing. Spring-managed transactions will simply work on that thread-bound PersistenceManager. This is particularly useful for JDO, as the PersistenceManager will always be in a consistent state, even if exceptions got thrown (in contrast to Hibernate).

All of this should work with any (relational) JDO 1.0 implementation. Please review those refinements and tell me about any gaps or inconsistencies!

I have been working with Spring more and more, and one of the best things about it isn’t the technology itself. The community is a pleasure.

On the mailing lists, I have been in awe of how helpful people are. Rod Johnson and Juergen Hoeller are machines on the list. I swear that they have clones that just sit on the list helping people out, while their other selves have a day job / work on the Spring code itself.

I also really appreciate how fast they add features / flush things out. If you sit on CVS HEAD you feel the waterfall of code, and see things evolve in front of you.

The “Spring guys” also aren’t religious. They don’t say “use Spring”, “How could you NOT use Spring”, “You have an EJB app? you are a moron”, etc. Hell, in Rod’s new book, he is very careful not to “push” Spring on the reader at all.

Spring is a very pragmatic approach that gives you a lot of a la carte functionality, allowing you to plug in and out other pieces.

Great job, and thanks.