Re: Where to publish an article?

From: RK <rajXesh_at_hotmail.com>
Date: 12 Nov 2002 05:52:04 -0800
Message-ID: <548b9514.0211120552.29dcde4e_at_posting.google.com>


Alexander.Kuznetsov_at_marshmc.com (Alexander Kuznetsov) wrote in message news:<ac5bc7c1.0211111242.636e8a67_at_posting.google.com>...
> >
> > Perhaps I did not quite understand, but how is your process more
> > efficient than the Oracle Sequence Numbers.
> >
>
> if the numbers are consumer in the middleware, you save a lot: a rounf
> trip across network for every number
>
> > Also instead of defining version_id as number, define it as date or
> > timestamp and set it to sysdate or systimestamp and using that in the
> > where clause should eleminate the 'nasty problem'
> >
>
> No way. On a powerful box there may be several updates with the same
> timestamp value. With DB2, timestamp are accurate to microseconds
> (0.000001 sec) and still attempts to have a unique index on
> MODIFIED_AT _DO_ fail on fast enough machines

You could go to http://www.oracle.com/oramag/misc/index.html?submit.html submit your article.

I am not convinced about the usability of this. Consider this portion of your SP.

  • First let's update the record.
  • Because the UPDATE statement is inside an ATOMIC block, an update lock
  • on the record is held until the transaction is committed. UPDATE AVAILABLE_NUMBER SET AVAILABLE_NUMBER = AVAILABLE_NUMBER + NUM_VALUES;
  • It's assumed there is only one record.
  • The statement will fail if there are multiple records. SELECT AVAILABLE_NUMBER INTO VALUES_END FROM AVAILABLE_NUMBER; SET VALUES_START = VALUES_END - NUM_VALUES;
  • The client will COMMIT the transaction and release the update lock END P1
Here you are assuming that the client will remain, for the lack of a better word, alive, to COMMIT and release the lock. What if the client asks for a set of numbers and dies. Arent all the other processes locked out because the transaction is not committed and they cant get the range of values?
  • rajXesh
Received on Tue Nov 12 2002 - 14:52:04 CET

Original text of this message