I have a legacy application running on Oracle 8.
Because Oracle 8 lacks of a proper Timestamp column type, we are using two columns for optimistic locking:

UPD_DTTS date // Date to seconds
UPD_DTMS number(3,0) // Milliseconds


I haven't found any explicit examples of this in the hibernate docs, but in digging around a bit I found that I could probably implement a CompositeUserType that implements the VersionType interface.

My confusion comes from not knowing how to specify, in my mapping file, that I want this type to be used by Hibernate for optimistic locking control.

According to the hibernate-3.0.dtd (if I'm reading it right) the only valid type for the version element is "integer". Or is that simply the default?

In any case, would the following be valid?

<class name="User" table="users" optimistic-lock="version">
<property name="username" column="USERNAME"/>
<property name="password" column="PASSWORD"/>
<version name="timestamp" type="myCustomCompositeTimestamp"></version>
</class>

Am I on the right track here?
Any help would be much appreciated...

yes it looks right.

I've managed to implement a UserVersionType to handle my legacy timestamp across two DB columns, but can't seem to map it as a version.

It works fine when I map it in the following way:

<property name="timestamp" type="myTimestampType">
<column name="UPD_DTTS" not-null="true"/>
<column name="UPD_DTMS" not-null="true"/>
</property>

but I get xml parse exceptions when trying the following:

<version name="timestamp" type="myTimestampType">
<column name="UPD_DTTS" not-null="true"/>
<column name="UPD_DTMS" not-null="true"/>
</version>

13:58:51,532 ERROR XMLHelper:59 - Error parsing XML: XML InputStream(15) Element "version" does not allow "column" here.
13:58:51,548 ERROR XMLHelper:59 - Error parsing XML: XML InputStream(16) Element "version" does not allow "column" here.
13:58:51,688 ERROR XMLHelper:59 - Error parsing XML: XML InputStream(15) Element "version" does not allow "column" here.
13:58:51,688 ERROR XMLHelper:59 - Error parsing XML: XML InputStream(16) Element "version" does not allow "column" here.

Am I doing something wrong or is this a deficiency in the DTD? (i.e. version only allows one column)
FYI, I'm using hibernate-3.0.2.

Thanks.

We don't support multi-column versions. However, you could pretty easily patch Hibernate to allow it. VERY strange requirement, however.

Strange requirement? Perhaps.
Stranger still is Oracle8's lack of a Timestamp type, and its Date type only supporting precision to the second. :-þ

Got any hints about what would be involved in adding support for this to Hibernate?

Thanks!

Why not just map milliseconds as the version number, and leave the date out of it.

I don't know why you think you need the date part for optimistic locking.

Legacy database... no control of schema.

I'm not suggesting change the db. Just have two props in the object model, one for optimistic locking, one not.

Let me elaborate in case I'm not being clear.
This is a legacy database schema with other legacy apps which modify the tables and use those two columns for optimistic concurrency control.
We absolutely need to use the same mechanism as those legacy apps do for tables that we share between us.

Also, if I only use the milliseconds column for version control, if user1 saves a change at "2005-04-29 02:30:45.666"
and user2 saves a change at "2005-04-29 02:30:46.666" (i.e. by chance the milliseconds match even though the saves are a minute apart) user1's changes get overwritten.

You don't need to check both column though!

What is the likelihood of the scenario you just presented occuring in practice??!

Likely or not, integrating with the current concurrency control mechanism is a real requirement for our application.
Don't shoot the messenger, I just work here! :-)

Seriously, though... is the change to allow mapping multi-column versions that distasteful (again, I'm willing to work on implementing it) that I need to resort to manual application version checking?

I sincerlely hope that's not the case...

why do you think my suggestion would not integrate?

it will.

Not in a 100% compatible way... if our end-users are occasionally presented with (seemingly) random optimistic lock error messages, it will eventually make its way back to us.
Also, there's no way your solution would be accepted by either peer or management review here, not when there is a well-established pattern.
If I can't map the auto-versioning to both columns, I have no choice but to move to application-managed version control.

Whoops, what I meant was overritten data... not optimistic lock messages.
Either way, your solution is a no-go for us here.