I've been following this discussion with a lot of interest and can't help but
offer my 2 cents...
I can think of a very good reason to use the database to generate primary keys:
the very realistic case where you will not be accessing the data in your
database exclusively through Java. I can think of many situations where
accessing your database via EJBs (or Java in general) would be far from
optimal. They all involve large scale, batch type accessing of your database
(reporting, sending mass emails based on column values in certain tables,
performing any complex queries with lots of complex joins, any sort of data
mining activity). If any of those scenarios involve (or may ever involve) doing
inserts it would be best to not have to call a Java program to get each new
primary key. Because this type of access is likely to be done in the
database's stored procedure language getting the key from the database seems to
make perfect sense.
Whether you should generate your primary keys in Java or the DB also kind of
depends on your view of the database. In my view it is the data (and
therefore the database) that is of primary importance in just about any
business-type information system. It is the data upon which I, if I put my
businessman's hat on, will base many new products and services. It is the data
upon which I will target ads and services at the individuals who will most
likely benefit from them. Various means of accessing, viewing, and modifying
that data (basically the applications that you write) will come and go based on
the demand of those same individuals, but the data will always remain. The
database can act as "neutral ground" for all of the various applications
accessing the data, regardless of the language the application was written in.
Java is just one such language (and entity beans are just one means of
accessing data from a database in Java). There are many others, each well
suited to particular tasks.
Finally, you can use the database to produce primary keys in a reasonably
database neutral fashion anyway. Just create a separate table with 2 columns,
a primary key column and a column that contains the next primary key for your
database. This table will always and forever just have a single row. Each
time you need a primary key value you read the value from the database, add one
(or some larger number if you want to create several new keys in one database
hit) to it and store the value back. Some care must be taken to ensure
transactional integrity, but that is pretty easily managed. Also, the queries
and updates that you need to do are very simple and should work the same
regardless of the database. Heck, even if you use a sequence that is DB
specific the amount of code that differs in your application as a result should
be very small and not worth fretting over too much. As far as your Java code
is concerned you should hide the details behind a Java interface anyway, so your
Java application code should always get a new primary key in the same way.
The approach above may create a single point of failure, but if you can't
access the primary key generator, you also can't access the database itself, so
you've probably got bigger problems anyway. Without relatively sophisticated
database mirroring systems the database is simply going to be a single point of
failure. Systems to achieve higher availlability can (and in my opinion should)
be implemented independently of Java.
On Tue, 03 Oct 2000, you wrote: > On
Oct 4, Tom Cook quoth: >
> > [EMAIL PROTECTED] writes:
> > > On Oct 3, Tom Cook quoth:
> > [snip]
> > > If you only have one database installation which contains all your data
> > > and everything you are running is in one box in one location in one hard
> > > drive without the need to operate in a degraded state or have graceful
> > > failover then, yes, then you are correct, there is no need for a
> > > distributed unique id generation system.
> > >
> > > In fact, it would be silly in such circumstances to try and reduce the
> > > amount of interdependence between your database vendor's proprietary
> > > implementation of key generation and your portable, write once, run
> > > anyhere, database-issues-are-the-containers-problem Enterprise Java Beans.
> > >
> > > I don't know what I was thinking. I stand corrected.
> >
> > Sheesh, calm down already.
>
> My apologies, but you quoted one paragraph of my response and ignored the
> part half a screen down which read "Reduce system interdependency, don't
> add." Specifically, and contrary to this you responded with a proposition
> that for no other reason than because your beans depend upon the database
> for storage, it is acceptable for your application to depend upon the
> database for another completely unrelated feature. I found this to be so
> full of assumptions I felt it necessary to point out just how many of
> these assumptions would have to be true in order for this to be the case.
>
> > It just seems to me (and I am no expert in the field) that it makes
> > sense to have your database tightly linked to the key generator for
> > that database.
>
> Your assertion here (and correct me if this isn't what the above sentence
> says), databases & their key generators should be tightly linked. I'm
> interpreting this to mean "makes sense to have your [EJBs] tightly linked
> to the key generator for [the] database [they are stored in]".
>
> > While EJBs are a nice abstraction, what you have
> > underneath is still a database,
>
> Without addressing the notion of "nice abstraction" I agree that there is
> in fact a database behind EJBs.
>
> > and it seems sensible for the database
> > to be responsible for the consistency of the data in it.
>
> Fact. (Consistency is one of the ACID requirements)
>
> > Of course
> > having one database generate keys for another is not sensible since,
> > as you point out, if your key generator goes down then your other
> > databases are stuffed.
>
> Agreed, however your Container is the transaction engine and therefore
> ultimately responsible for the behavior of both. Recall that your
> proposal was for the database to be the key generator for the container
> which the beans would call upon for new keys.
>
> > You may well argue that we want to be able to move this to any
> > database backend;
>
> Corrollary: flexibility to deal with unforseen future requirements is a
> good thing. Agreed 100% and I would argue that except in the most trivial
> of applications this is essential.
>
> > in my experience of deploying
> > enterprise applications (which is a bit more extensive than my
> > experience of designing them), the deployment architecture is well and
> > truly fixed early on.
>
> Generally true but if they weren't liable and even likely to move, then
> why would things like SQL92, jdbc, IIOP and J2EE exist?
>
> > Enterprise applications are not the sort of thing you want to be able
> > to install on everyone's desktop;
>
> (Very) generally agreed, but that has little or nothing to do with your
> assertion.
>
> > that's the point of it being an enterprise application.
>
> Disgree. The "point" of being an enterprise application is that it
> supports a core aspect of a company's business process. Not where it is
> installed or how it runs.
>
> > It's very likely that it will be deployed to one place on earth, and
> > not moved.
>
> STRONGLY disagree. Most especially, in this age of fast moving companies
> with product development being concurrent with product implementation,
> and mergers happening left and right, it is more than likely that an
> enterprise application, once deployed is A) going to be modified, and B)
> going to change it's operating environment. If this weren't true then the
> need for things like J2EE wouldn't be there and everyone could just write
> their application in JCL and COBOL happy knowing that "it will be deployed
> to one place on earth, and not moved."
>
> Regardless, even if it were true that an enterprise application would "be
> depoyed ... and not moved", what if your application is a product to be
> sold to others, would they not have a say in which database system is used
> in the deployment environment? It is for these reasons the "[EJB]
> architecture defines six distinct roles in the application development and
> deployment life cycle." [EJB1.1, s.3.1]
>
> > Just my two bits worth...
>
> As you can see, we agree on nearly many things but not a thing that you
> said has anytyhing to do with your assertion that databases & their key
> generators should be tightly linked.
>
> You have said, in a public forum for *EJB development*, that it is an
> acceptable (if not desirable) practice to have your beans use the
> underlying database to generate primary keys. I argue that is contrary to
> the spirit and intent of Enterprise Java. All I ask is that you either
> support that statement with an argument addressing it, or retract it as
> nothing more than an usupported opinion.
>
> Some people see this forum as a source of useful and relevant information.
> I find your advice to be not only wrong but Bad Advice liable to lead the
> unwary into building unecessarily complex or deficient applications. While
> I don't consider you to be anything other than a consummate professional,
> you have touched a sore spot of mine by advocating that a Bad Idea be used
> simply because it's there and without looking at what it's implications
> are. Someone who uses database key sources and EJB at the same time is
> hobbling their project in a way that is entirely contrary to the notions
> of Enterprise Java and flexible computing at any scale.
>
> If you are going to take a position such as that, defend it. Otherwise
> admit you have no basis for this opinion. I am willing to be convinced,
> but I need an argument and so far you have done nothing more than state a
> position.
>
> > "We rarely find that people have good sense unless they agree
> > with us."
> > - Francois, Duc de la Rochefoucauld
>
> I couldn't agree with you more.
>
> C=)
>
> --------------------------------------------------------------------------
> Some people mistake the positions I take with the beliefs that I hold.
> --------------------------------------------------------------------------
> Caskey <caskey*technocage.com> /// TechnoCage Inc.
> --------------------------------------------------------------------------
> Oh no! Space monkeys are attacking! -- eddie izzard
>
>
>
>
> --
> --------------------------------------------------------------
> To subscribe: [EMAIL PROTECTED]
> To unsubscribe: [EMAIL PROTECTED]
> Problems?: [EMAIL PROTECTED]
--
_______________________
Vincent Sheffer
Director of Operations
Telkel, Inc.
_______________________
--
--------------------------------------------------------------
To subscribe: [EMAIL PROTECTED]
To unsubscribe: [EMAIL PROTECTED]
Problems?: [EMAIL PROTECTED]
