|
From: Timo V. <sic...@gm...> - 2003-08-08 13:36:21
|
Hi! > You may run into problems with that solution. Depending upon the > precision of how the data is stored in your database, you may have a > wide window where multiple objects have the same date. > > Let's just say, for sake of arguement, that your database only holds > date to the nearest second, and loses any sub-second accuracy. If > two objects are created within the same second in your app, and then > stored to the DB, when they are pulled back they will have the same > created time, and thus your code will think they are the same object. I don't thinks there's a problem: As I said, equals() is still id based, only hashCode() is "created" based. And its no problem that differerent (according to equals()) instances have the same hashCode(). It perfectly holds the contract! The database just should not truncate any bits! Otherwise there will be problems, of course. > If you want a better solution for this scheme of generating a > hashcode, use a GUID / UUID generator. These take time / machine > (usually IP address in Java, network card MAC address in C.) and > usually other "unique/random" parameters into account for creating an > ID. Using a good GUID / UUID generator with a good algorithm will > GUARANTEE that no two id's are the same, without the need for any > synchronization between machines (like hi/low, sequence, etc > require). Since Java based GUID / UUID generators generally use the > machines IP address as part of the algorithm, you need to be sure > that the IP address of each machine is unique. This is usually not a > problem in a lan / lan cluster environment. Also make sure your > algorithm doesn't mistakenly use 127.0.0.1 as it's IP address, as all > machines have that IP. I don't want to use GUIDs in some cases. I sometimes HAVE to use database native sequences/autovalues. Regards, Timo |