Hi
Richard,
Thanks for your kind words!
Just trying to finally cut through the confusion and present a definitive set of
patterns for people to use. In regrards to your comment on UUID, I
must ressurect some counter-points that were used on TheServerSide, I am
interested in your perspective here (originally posted by Steve
Woodcock):
1) the class is
for use on a single machine only - so would have problems on a cluster - you
would still have to add the inet address
2) it uses a Thread.sleep call so I am not sure how this would affect its use inside all EJB containers - when you are not supposed to manage threads manually
3)the values are static and are incremented uniquely through use of a static mutex object which seemed to me could potentially cause problems with the container managing concurrent access
4) the count value used to provide the last 4 digits is always initialised from the short.MIN_VALUE (0X-8000) and counted down from there - this seemed too much of a chance of collision if the clock is reset
2) it uses a Thread.sleep call so I am not sure how this would affect its use inside all EJB containers - when you are not supposed to manage threads manually
3)the values are static and are incremented uniquely through use of a static mutex object which seemed to me could potentially cause problems with the container managing concurrent access
4) the count value used to provide the last 4 digits is always initialised from the short.MIN_VALUE (0X-8000) and counted down from there - this seemed too much of a chance of collision if the clock is reset
"As an added point which I forgot to mention - I also
ran a couple of tests for app servers that use more than one VM on the same
machine - using rmi UID in more than one VM simultaneously produces sequnces
where the first 6 characters in both is the same - the last set are always the
same sequence -8000 increasing by one each time and the only difference is the
millisecond value - therefore there seems too much liklehood that the method
could be called in the same millisecond in both VMs which would clash and
produce the same result. You would have to add other information such as a
SecureRandom to prevent this happening.
"
"
Given this information
Richard, it seems that UUID is not good enough to be used on its own (not
within a reasonably large-scale clustered deployment). The only recourse is to
combine UUID's key with other algoriths as the UUID pattern in my book does, but
in that case why use UUID at all??
In regards to your comment on
improving the Spec, I can see people immediatly claiming that not implementing
your own PK generation algorithm is bad idea from a portability perspective. If
you rely on the algorithm provided by your app. server, then it is possible that
the same algorithm may not be available on other app. servers. This is
definitly not something that a component vendor (if there are any out there)
would want to do.
thoughts?
Floyd
-----Original Message-----
From: A mailing list for Enterprise JavaBeans development [mailto:[EMAIL PROTECTED]]On Behalf Of Richard Monson-Haefel
Sent: Monday, August 27, 2001 11:05 PM
To: [EMAIL PROTECTED]
Subject: Re: Primary Key Generation - chapter posted on TheServerSide.com
Nice work,
Floyd. I think this chapter will be valuable to EJB developers. One thing
I would change is to use Java RMI's UUID generator (java.rmi.dgc.VMID)
instead of creating a custom one -- its already there so why not use it? I did,
however, enjoy your explanation of UUID and I think people can learn a lot from
that discussion. As a side note: I would never use another enterprise bean
as the id generator because the overhead is unwarranted. Other then that I
thought the chapter was excellent.
From: A mailing list for Enterprise JavaBeans development [mailto:[EMAIL PROTECTED]]On Behalf Of Richard Monson-Haefel
Sent: Monday, August 27, 2001 11:05 PM
To: [EMAIL PROTECTED]
Subject: Re: Primary Key Generation - chapter posted on TheServerSide.com
One problem with EJB 2.0 is that auto-generated primary keys are not explicitly accommodated in the CMP programming model. This is a problem that I have commented on several times over the past three years. The largest barrier to auto-genterated primary keys today is that the spec now requires that primary key fields be set in the ejbCreate method for CMP beans. If not for this requirement -- which means that the key value must be known by the bean provider during the ejbCreate method -- vendors could easily support auto-generated primary keys in a portable way.
It
