Sorry for this being off topic a bit.....this is probably better discussed
in some sort of EJB User Mailing List rather than JBoss itself.
True. I put it up since some databases don't have that concept. Also,
there is no real bit twiddling needed:
#1 On startup:
-----------------------------------------------------------------------
Load Data From Database into Integer object (assumes last 8 bits are 0)
Save value into object
Incremement by 256
Store new data into Database
#2 On key gen:
-----------------------------------------------------------------------
Give current value stored in object to requestor
Increment current value by 1
If you've incremented 255 times, then it is time to get a new key.
(Repeat step #1 above)
Just that conceptually you are incrementing the low side and keeping the
high side of the integer the same. :)
There really is no large difference between using a counter and a table to
store the high value...just that a table can be done in all databases, so if
your application needs to be vendor/db neutral, then this can be a better
mechanism. I think that to make it truely vendor/db neutral, you have to
use an entity bean for the high value....but I'm not positive about that.
Alan
-----Original Message-----
From: David Jencks [mailto:[EMAIL PROTECTED]]
Sent: Tuesday, June 26, 2001 5:36 PM
To: [EMAIL PROTECTED]
Subject: RE: [JBoss-user] Re: random keys
Hi,
You can get the same effect with the generators and sequences I am familiar
with by requesting a large step or increment. Then you don't need to do bit
twiddling. If your db supports generators/sequences use them.
david jencks
On 2001.06.26 16:38:03 -0400 "Wood, Alan" wrote:
> >>
> >> If you're going to run in multiple jvm's, the solution is a counter
> >> table. Lock the counter table when you update the count. This doesn't
> >perform
> >> as bad as it sounds.
> >
> >Which would leave this alternative of course. It somehow seems like
> >overkill to me, but it may very well be the option I land on.
> >
> >Thanks for the input.
> >
> >Cheers
> > Bent D
>
> An alternative to this is discussed in many forums (including
> "theserverside.com"). It sacrifices loss of key space for a bit of
> performance. I'm just reading up on it, but the basics are:
>
> Make a key an integer with a 24 bit high index value and an 8 bit low
> index
> value. (You can use any bit split you would like. Use 32 & 32 if you
> needs
> lots of room in the key space) The result would be a true 32 bit integer.
>
> Hold the last used 24 bit high index value in the database exactly as
> mentioned in the previous post.
>
> Create an SessionBean that will generate a unique key for you. Make it
> stateless, although it will hold state. (The state in this case is
> discardable...if the state is missing, a new one can be generated.)
>
> Either encapsulate the high value into an entitybean, or just use direct
> sql
> in the SessionBean to load the high value when the bean is created.
> Since
> the SessionBean is stateless, it will probably be created in a pool (set
> it
> to a small # of instances) and only get initialized once per run of the
> EJB
> server. (Not a requirement though)
>
> Now, generate the lower order keys as you are called. Just increment the
> low value, and append it to the high value to create the full integer.
> (Or
> in other words, add 1 to your saved key).
>
> Detect if you are going to go into the next high value range, and if you
> are
> then reload the high value from the database (incrementing it when you
> do).
>
> This method requires the following:
>
> You can atomically "read the high value", "increment the high value",
> "write the high value" at the database level. (SELECT FOR UPDATE,
> Lock the record, or whatever needs to be done. I believe if you put
> it into an entity bean, then this will already be done for you if you
> make an operation (method) that does the increment and mark the bean
> for transaction level REQUIRES_NEW, or REQUIRES ??).
>
> This allows many different SessionBeans across multiple VMs to generate
> unique keys (since they will all have different high values). It will
> result in some of the integer space not being used (due to shutdowns of
> the
> server, etc.) It should also allow pooling of the unique key generator
> so
> that you have less of a bottleneck there during entity creation.
>
> I'd still keep the pool size limited though so that your key space isn't
> used up at each server shutdown.
>
> Keep in mind, I'm still learning and if someone could correct me if I got
> something wrong, I'd be much appreciative. But, I've read this mechanism
> a
> few times and it seems solid enough.
>
> Hope this helps,
>
> Alan
>
>
> NOTICE: This transmission, and any attached files, may contain
> information from
> Genaissance Pharmaceuticals which is confidential and/or legally
> privileged.
> Such information is intended only for the use of the individual or entity
> to whom
> this transmission is addressed. If you are not the intended recipient,
> you are
> hereby notified that any disclosure, copying, distribution or the taking
> of any
> action in reliance on the contents of this transmitted information is
> strictly
> prohibited, that copies of this transmission and attached files should be
> deleted
> from your disk directories immediately, and that any printed copies of
> this
> transmission and attached files should be returned to the above address.
> If you
> have received this transmission in error, please notify Genaissance by
> telephone
> (toll-free, 1-877-ISOGENE) or e-mail immediately. Thank you.
>
>
****************************************************************************
***
> This note confirms that this email message has been swept by
> Genaissance Pharmaceuticals Anti Virus defense system for the
> presence of computer viruses.
>
****************************************************************************
***
>
> _______________________________________________
> JBoss-user mailing list
> [EMAIL PROTECTED]
> http://lists.sourceforge.net/lists/listinfo/jboss-user
>
_______________________________________________
JBoss-user mailing list
[EMAIL PROTECTED]
http://lists.sourceforge.net/lists/listinfo/jboss-user
**********************************************************************
This note confirms that this email message has been swept by
Genaissance Pharmaceuticals Anti Virus defense system for the
presence of computer viruses.
**********************************************************************
NOTICE: This transmission, and any attached files, may contain information from
Genaissance Pharmaceuticals which is confidential and/or legally privileged.
Such information is intended only for the use of the individual or entity to whom
this transmission is addressed. If you are not the intended recipient, you are
hereby notified that any disclosure, copying, distribution or the taking of any
action in reliance on the contents of this transmitted information is strictly
prohibited, that copies of this transmission and attached files should be deleted
from your disk directories immediately, and that any printed copies of this
transmission and attached files should be returned to the above address. If you
have received this transmission in error, please notify Genaissance by telephone
(toll-free, 1-877-ISOGENE) or e-mail immediately. Thank you.
*******************************************************************************
This note confirms that this email message has been swept by
Genaissance Pharmaceuticals Anti Virus defense system for the
presence of computer viruses.
*******************************************************************************
_______________________________________________
JBoss-user mailing list
[EMAIL PROTECTED]
http://lists.sourceforge.net/lists/listinfo/jboss-user
