In the ideal world, we would all be able to change an existing database schema to add the simple version column and make this a moot point.

However, my scnerio is such that we have a legacy application that will be accessing the same DB instance as our new J2EE application.

Since most web apps have long running application transactions, and I cannot do a concurrency check on detached objects due to the lack of a version column (or even if I had one, the legacy app would need changed to recognize and update that field), what approach should I take?

Another thing that throws a wrinkle in this situation is the need for maintaining a log of changes to the object. This also can't be done out of the box with detached objects (an interceptor onFlushDirty() call on a detached object has the previous object as null)

One idea we used with entity beans before we switched to Hibernate was to create a 'snapshot' of the data right when it was loaded the first time. Then before we did the update, we did another select and compared the snapshot data, which gave us two things, a way to compare that data had not changed between the two selects, and a way to see which data had changed from the user side. The snapshot would get removed if it was either not created or accessed during that transaction, which assumed that all objects were loaded in one session, and saved in the next session, which was not a constraint for us.

Can anyone provide some suggestions on what I could to to accomplish the same goal? i.e. concurrency and an audit trail?

I'd look into the optimistic-locking=dirty and select-before-update=true options.

Audit trail is often implemented via a trigger. I usually shy away from triggers, but allow their use for audits because it is invisible to the application