At 03:10 PM 3/27/00 -0800, you wrote:
>
>> it looks like the IDBroker just returns one single int...is that a
>> concatinated high/low value?
>
>It just returns a simple int like a simple Oracle sequence. We were
>originally thinking of returning a high/low value but John and I decided it
>wasn't necessary.
>
Before this gets too mature, can I suggest that the IDBroker return a
64-bit long rather than a 32-bit int?
I know that this is slightly more expensive computationally.
However, in enterprise object systems, signed 32-bits (2 billion
positive combinations) is really too few. This is particularly
true under these conditions
* if you have ID wastage (due to large Oracle sequence increments
accompanied by server cycling)
* if you have many deletes and new object insertions
* if you are in a repetitive run environment (i.e. regression testing)
* if you are in a distributed environment and need to delegate
large ranges of ID's to different allocating servers
We are working with a 1 Terabyte Oracle database with some tables
approaching 1 billion rows. In some places, we took short cuts for
"efficiency" and assumed that an ID would fit in a signed 32-bit
integer, and we regret it. We are potentially faced with a major
database maintenance effort or a major code rework.
It should be noted that if the system developer knows for a fact that
his ID's will never go above a certain number, his primary key ID
columns do not need to be large enough to support the full 64-bit
possible range (20 digits). However, having the Java code use
long's positions you better to be a true enterprise-quality component.
Thanks for all the good work you are doing.
Stephen
------------------------------------------------------------
To subscribe: [EMAIL PROTECTED]
To unsubscribe: [EMAIL PROTECTED]
Problems?: [EMAIL PROTECTED]
