Stephan:
Let me back up and see if I can assist you with what you actually want
to do.
If I am not mistaken, you were looking to add rows to a database table
and ensure
that a unique row-id (key) was assigned to each row, but had no column
suitable
for that purpose, so you wanted to generate one as the bean was added.
This fairly common real-world practice is an SQL nightmare. As
originally designed,
SQL cared nothing for keys, triggers, database definitions, or any ot
the amenities
that practical every day use has brought -- in a different way for every
brand of
DBMS in existence! Sun doesn't favor any particular persistent storage
in its EJB
architecture. In fact, it takes a fairly active role on enforcing the
lowest common
denominator just to make sure that EJBs are in fact portable objects.
Why not build EJBs with null keys? Because EJBs are expected to be
complete
objects. If a server detects a system failure and has to shut down, it
has to either
discard or commit its EJBs. Ideally, it will commit in such a way that
when the server
recovers, it will be in exactly the same state as before the failure. To
do THAT, it
needs to be able to commit, even if it's only to a recovery store, and
to do THAT,
you need unique keys. A null is about as NON-unique as you can devise!
So much for theory. As mentioned, this is a very common task. So common,
in fact,
that the EJBWizard tool generates a special block of commented-out code
in its
bean detail JSP - a block of code that looks up another type of EJB
which maps a
table used to generate unique keys.
In the way I have used it, to create a row:
1) you acquire the key-generator EJB that contains the next available
key for the
table you want to add that row to,
2) decant that key,
3) advance the generator to the next key value (using a business
method),
4) then create your data row, passing that key as a parameter to the
create
method. It doesn't allow for rollbacks, but then, I only wanted a unique
key -- "holes"
in the key set caused by post-generation failures were not an issue.
You could also manage this process with a session EJB that contained the
requisite logic, but the net effect is the same. The case where data is
also being added
from outside the EJB is a little more complex, but the basic process
remains the same.
----
To unsubscribe, send email to [EMAIL PROTECTED] and
include in the body of the message "unsubscribe jonas-users".
For general help, send email to [EMAIL PROTECTED] and
include in the body of the message "help".
