The OJB and Spring presentation at PhillyJUG seemed to go pretty well -- at least based on the questions during and discussions after. The slides are available for download now -- the references to "Thomas" are to Thomas Risberg, who who was doing the Spring presentation.
No one in the audience had used OJB but a couple people had used Hibernate, so I got a lot of "Hibernate works this way, how does OJB do it?" type questions. When I talked about designing applications for O/R mapping I wound up highlighting how things apply in the Hibernate world as well. Was sort of funny. I also learned that a lot of people are not writing multi-thread/multi-vm safe Hibernate apps right now as they tend to use the obtain-object, copy properties onto some web tier transfer thingie (like a dynabean), then copy off of the dynabean back onto the same object from the previous request, and re-persist that object. The problem here is that data that has changed gets overwritten, and worse, objects in collections can be re-inserted or deleted via a "most recent change wins" situation =(
Repeat after me three times -- start trasnaction, re-query for your entity, apply changes to the freshly obtained one, store it back (commit transaction). Do this all in the context of a transaction.
If you need to support long-lived transactions (they open page, walk away for five minutes, come back, submit form) and cannot risk concurrent modification use optimistic transactions and make sure to take the user to a conflict resolution page if the transaction fails (someone updated the data while they were filling out their form). It is almost always a bad idea to just blindly take the most recent submission and store it, particularly when it is an object graph where a lot of things are just loaded for ancillary reasons (ie, in the referenced collections).