These old forums are deprecated now and set to read-only. We are waiting for you on our new forums!
More modern, Discourse-based and with GitHub/Google/Twitter authentication built-in.

View unanswered posts | View active topics


Board index » Hibernate & Java Persistence » Hibernate Users

All times are UTC - 5 hours [ DST ]


Forum locked This topic is locked, you cannot edit posts or make further replies.  Page 1 of 1
  [ 15 posts ] 
  Previous topic | Next topic 
Author Message
abulheath
 Post subject: Versioning / timestamp and Daylight savings?
PostPosted: Mon Oct 27, 2003 2:01 am 
Beginner
Beginner

Joined: Wed Sep 17, 2003 10:25 am
Posts: 36
I realized that after daylight savings took effect, every call to update an entry into my databaes created before day light savings took effect would result into a StaleObjectStateException. I also realized that the query that hit the database had two where clauses, one for unique id and one for the timestamp column beign equal to a value that was always an hour off from what it was in the database. What is going on here?
Top
 Profile  
 
nickvajberg
 Post subject:
PostPosted: Mon Oct 27, 2003 3:22 am 
Senior
Senior

Joined: Tue Oct 21, 2003 8:15 am
Posts: 186
Yeah, that's because daylight savings goes one hour BACK now and everything that happended the last hour is causing trouble. The hour is happening one more time...

Using timestamps for versioning is flawed for this reason when the timestamp format doesn't include a daylight savings attributte.
Top
 Profile  
 
abulheath
 Post subject: yeah..
PostPosted: Mon Oct 27, 2003 3:58 am 
Beginner
Beginner

Joined: Wed Sep 17, 2003 10:25 am
Posts: 36
Thanks for the reply. Just when I thought I had a handle on how Hibernate works... I have a hack already in the works to fix this but it is expensive. I guess I will not be using timestamps due to this flaw and go with setting timestamps manually. Unless someone out there has got a solution for this. We are using Hibernate 2.0. Is this fixed in Hibernate 2.1.x?

How does hibernate get at the verion/timestamp in the case where one uses a timestamp field per entity and UUID's?

Thanks..
Top
 Profile  
 
nickvajberg
 Post subject:
PostPosted: Mon Oct 27, 2003 6:32 am 
Senior
Senior

Joined: Tue Oct 21, 2003 8:15 am
Posts: 186
Actually, I don't think Hibernate can fix this because it simply maps to the native timestamp of the underlying database.

For versioning in real-life solutions, timestamps are out of the question.

There should be a relative timestamp, i.e. milliseconds elapsed since time X. This should be possible to implement in the hibernate layer, using two 'long' columns (beeing HI/LO parts of a 64 bit relative timestamp as 32 bit last for only 48 days... cus' 2^32-1 ms is about 48 days. 64 bit outlasts the application, that's for sure :-)
Top
 Profile  
 
gavin
 Post subject:
PostPosted: Mon Oct 27, 2003 7:37 am 
Hibernate Team
Hibernate Team

Joined: Tue Aug 26, 2003 12:50 pm
Posts: 5130
Location: Melbourne, Australia
I'm sure this is fixable by localizing the times on both Java and database.
Top
 Profile  
 
nickvajberg
 Post subject:
PostPosted: Mon Oct 27, 2003 9:44 am 
Senior
Senior

Joined: Tue Oct 21, 2003 8:15 am
Posts: 186
In general, no, because timezone information is handled very differently.

E.g. in DB2, you need to look at TimeZone options.

MS SQL: no timezone info stored at all (at least not through my jdbc driver)

Postgres: 'SET TIME ZONE'

Oracle: Look at this: "http://groups.google.com/groups?hl=no&lr=&ie=UTF-8&oe=UTF-8&selm=3EB06EE3.D7F62B71%40yahoo.com"

On Sybase, you may need this:
TZ=GMT0BST
export TZ

/opt/sybase/bin/dataserver -d/sybase/db/master.dat -sSYBASE1 \
-e/sybase/msgs/errorlog -i/opt/sybase

Also, earlier SUN JRE's are braindead about timezones.

Also, here is a nice piece i found:

"SimpleDateFormat dateform = new SimpleDateFormat ("yyyy-MM-dd
HH:mm:ss.SSS");
dateform.setTimeZone(TimeZone.getTimeZone("GMT"));

Now, use Date datein = dateform.parse(rs.getString(1)) and
rs.setString(1,dateform.format(dateout)) to get/set the datetime column.
Caution: due to the bug in the SQL 2000 JDBC Driver (inconjunction with the MS JVM), rs.getString(1) may return a value 1 hour off.

To circumvent this, I use CONVERT(varchar, datetimecolumn, 121) in the SELECT statement.

For compatibility with other databases, I put that SELECT in a stored procedure."
Top
 Profile  
 
nickvajberg
 Post subject:
PostPosted: Mon Oct 27, 2003 9:45 am 
Senior
Senior

Joined: Tue Oct 21, 2003 8:15 am
Posts: 186
I guess the moral of the story is... DON'T use timestamp for reliable versioning.
Top
 Profile  
 
ChennaiVasi
 Post subject:
PostPosted: Mon Oct 27, 2003 11:15 am 
Newbie

Joined: Mon Sep 15, 2003 6:44 pm
Posts: 8
I'm also facing the similar problem. The quick fix we did on the Dev Environment was to update the TS field to the current TS for all the existing records.

Does anyone have any permenant fix (for MS SQL Server DB)
Top
 Profile  
 
abulheath
 Post subject: yes..
PostPosted: Mon Oct 27, 2003 12:18 pm 
Beginner
Beginner

Joined: Wed Sep 17, 2003 10:25 am
Posts: 36
I agree...No timestamps seems like where I would like to go until I get a clean solution to this issue. I still did not hear how Hibernate checks on the timestamps? Does it read it from the database for the entity? How does hibernate figure out the version of the entity it is trying to update?

Thanks for everyone's input..
Top
 Profile  
 
gduprey
 Post subject:
PostPosted: Mon Oct 27, 2003 12:55 pm 
Newbie

Joined: Wed Oct 15, 2003 4:31 pm
Posts: 17
why not use normal integer based record versions? It takes the secondaryt meaning out of the version (i.e. time/date) and should always work regardless of external conditions.
Top
 Profile  
 
ChennaiVasi
 Post subject: not really
PostPosted: Mon Oct 27, 2003 1:01 pm 
Newbie

Joined: Mon Sep 15, 2003 6:44 pm
Posts: 8
The whole point behind using Timestamp versioning (atleast for me) is beacuse
1. we don't need to set the TimeStamp thru application
2. We can use that field to figure when was the last time a particulare record is changed.

I don't think integer versioning will give me that flexibility.
[/list]
Top
 Profile  
 
gduprey
 Post subject: Re: not really
PostPosted: Mon Oct 27, 2003 1:13 pm 
Newbie

Joined: Wed Oct 15, 2003 4:31 pm
Posts: 17
ChennaiVasi wrote:
The whole point behind using Timestamp versioning (atleast for me) is beacuse
1. we don't need to set the TimeStamp thru application
2. We can use that field to figure when was the last time a particulare record is changed.

I don't think integer versioning will give me that flexibility.


No it won't, but you could consider using a time stamp for versioning as overloading the meaning of the field - especially if you do later go back and do math/computations from it. Ideally, version is just a unique ident with no other meaning (except that when versionA != versionB, there has been a change behind the scenes).

Anyway, I think hibernate has a timestamp type that can be setup independent of being associated with the versioning field so you could just switch to two fields (because they are doing two seperate things). Alternatly, keep the version an int and add an interceptor into your app that maintains a last updated timestamp.

We created a base DAO that all others inherit that has the creation timestamp, user reference to the person who created it, a last updated time stamp and user reference to the person who last updated it and it works great. Integrated into our base DAO object and our application session factory (wrapper around session factory that sticks an interceptor for the app in), it's available to all DAOs/tables without the programmers needing to do anything to get that functionality.
Top
 Profile  
 
ChennaiVasi
 Post subject: i agree
PostPosted: Mon Oct 27, 2003 3:23 pm 
Newbie

Joined: Mon Sep 15, 2003 6:44 pm
Posts: 8
That's an excellent idea.

But i don't have any version entry in my class mapping xml. I only have the TimeStamp field. But according to the documentation, timestamp is an alternative to the versioning. Also the basic question of whethre it will solve the Day Light issue is still unknown I think,,,

From the Hibenate Doc:

Quote:

4.1.7. version (optional)
The <version> element is optional and indicates that the table contains versioned data. This is particularly useful if you plan to use long transactions (see below).

<version
column="version_column"
name="propertyName"
type="typename"
/>
column (optional - defaults to the property name): The name of the column holding the version number.

name: The name of a property of the persistent class.

type (optional - defaults to integer): The type of the version number.


Version numbers may be of type long, integer, short, timestamp or calendar.

4.1.8. timestamp (optional)
The optional <timestamp> element indicates that the table contains timestamped data. This is intended as an alternative to versioning. Timestamps are by nature a less safe implementation of optimistic locking. However, sometimes the application might use the timestamps in other ways.

<timestamp
column="timestamp_column"
name="propertyName"
/>
column (optional - defaults to the property name): The name of a column holding the timestamp.

name: The name of a JavaBeans style property of Java type Date or Timestamp of the persistent class.


Note that <timestamp> is equivalent to <version type="timestamp">.



and having both will conflict or not ( from what I understand from ur reply, it doesn't).
Top
 Profile  
 
jfifield
 Post subject:
PostPosted: Mon Oct 27, 2003 6:04 pm 
Regular
Regular

Joined: Tue Aug 26, 2003 3:09 pm
Posts: 58
Not sure if this wil help with versioning, but... We store all dates in the database as GMT, and use a custom type to convert to/from the local timezone. A disadvantage with this approach is that you have to make sure all other means of reading or writing the database (other than hibernate) can perform the same conversion.

Joe
Top
 Profile  
 
TealWren
 Post subject: MSSQL SQL Server Daylight Savings time
PostPosted: Wed Feb 21, 2007 5:51 pm 
Regular
Regular

Joined: Tue Sep 09, 2003 9:37 pm
Posts: 56
Location: Ogden, Utah, USA
We had a similar problem. Any record with a version between 2 am through 8 am on the date daylight savings turns on or off (>2007 DST or <2007 DST) would not be able to be updated since the update statement would include a version timestamp that was an hour off. We got a StaleObjectException.

We had the issue with JVM versions 1.3.1_07 and 1.4.2_12. We use the Opta MSSQL driver, and the standard DB2 driver.

We use Hibernate 2.1, MSSQL 2000 sp4 and DB2 UDB 7.2. DB2 did not have this issue, only MSSQL. Apparently this is because MSSQL doesn't store timezone information with timestamp types in the database.

As a solution, we wrote our own extension to the hibernate timestamp type. It explicitly sets the timezone when retrieving the date from the database. This fixes the problem mentioned above for MSSQL, and has no adverse affects on DB2 either. We replaced "timestamp" in our hbm.xml file(s) with com.mvsc.persistence.TZTimestamp and the problem was solved.

Hope this is helpful to someone out there!

Jenica
jenica -at- mvsc.com

Code:
public class TZTimestamp extends net.sf.hibernate.type.TimestampType {
public static GregorianCalendar DEFAULT_CALENDAR = new GregorianCalendar();
  public Object get(ResultSet rs, String name) throws SQLException {
    return rs.getTimestamp(name, DEFAULT_CALENDAR);
  }
}
Top
 Profile  
 
Display posts from previous:  Sort by  
Forum locked This topic is locked, you cannot edit posts or make further replies.  Page 1 of 1
  [ 15 posts ] 

Board index » Hibernate & Java Persistence » Hibernate Users

All times are UTC - 5 hours [ DST ]

You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum

Search for:
© Copyright 2014, Red Hat Inc. All rights reserved. JBoss and Hibernate are registered trademarks and servicemarks of Red Hat, Inc.