Hi Tim,
thanks for your effort. Indeed you made some points clearer
for me now. I have written my own workaround in the
meantime, which works very nice, and additionally shouldn't
be a performance break.
As soon as I have time, I will put this helper class
to my Open-Source-Software section on my homepage
under http://www.httpservice.de/jcorner
Thanks again,
Stephan
Tim Holloway schrieb:
>
> 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".
--
_________________________________________________________________________
Stephan Bauer, Dipl. Inform. (FH) IT-Freelancer
Siemensstr. 46 Bauer Internetprojects.de
D-94315 Straubing Tel.: +49 9421 9749549
E-Mail: [EMAIL PROTECTED] Fax: +49 9421 9749550
http://www.internetprojects.de Mobil: +49 172 9795002
Software-Design, Implementation & Webhosting
_________________________________________________________________________
----
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".
