Hi Floyd,
As Stever Wookcock and Jim Nicolson pointed out, the java.rmi.server.UID
uses Thread.sleep() which is a real no-no in EJB. Therefor its
immediately disqualified from use by bean developers. In addition, your
research with multiple VMs and the use of VMID seems to indicate that
collisions are more likely, which is obviously undesirable. It seems to
me that your UUID design described in your chapter is a better option
then the java.rmi.dgc.VMID.
With regard to portability and auto-generated primary keys: If the
deployer chooses to use the database's native facilities (e.g.
auto-increment) this would, of course, not be an issue. I don't think we
are concerned about end users changing databases. I have been around
longer them most and have rarely seen this occur (a point also made by
Jay Walters in a related e-mail).
The real concern is changing EJB vendors or using multiple EJB vendors
together on top of the same database. In the later case you bring up a
valid point about the consistency of values generated by the EJB vendor
for primary keys (provided they are not using the database's native
facilities). One vendor may use a different algorithm then another. On
one level this is good. Let each vendor complete based on the strength
and performance of their auto-generated primary keys. On another level,
as you pointed out, it could be problematic as two products could
produce very different kinds of values. I believe the solution to this
problem, from a specification perspective, is to specify at least one
algorithm that must be support, but also allow vendors to offer their
own algorithms. If the end-user feels that portability is most
important then they will chose to use one of the algorithms mandated by
the specification, otherwise they may use whatever algorithm they tje
vendor supports. Now the problem is choosing the correct algorithms for
the specification to mandate.
Richard
--
Richard Monson-Haefel
Author of Enterprise JavaBeans, 3rd Edition (O'Reilly 2001)
Co-Author of Java Message Service (O'Reilly 2000)
http://www.jMiddleware.com
Floyd Marinescu wrote:
> 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 "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.
> -----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.
>
> 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
===========================================================================
To unsubscribe, send email to [EMAIL PROTECTED] and include in the body
of the message "signoff EJB-INTEREST". For general help, send email to
[EMAIL PROTECTED] and include in the body of the message "help".
