Hélène JOANIN wrote:
> Olivier Richaud wrote:
> >
> > I'm using a container manager bean who relies on a table defined as follows:
> >
> > create table my_table ( id char(10) UNIQUE PRIMARY KEY, ....);
> >
> > As one can see, the first column stands for the primary which is mapped onto
> > a corresponding entity bean. Its home is defined as follows:
> >
> > interface MyBeanHome extends EJBHome {
> > MyBean create(String id) throws CreateException, DuplicateKeyException,
> > RemoteException;
> >
> > ....
> > }
> >
> > As one can see, I have included the exception list the DuplicateKeyException
> > because I want to be notified that there exists a bean (that is a row in the
> > table) with the same primary key. My dream was to be notified by a
> > DuplicateKeyException that such a primary key is in use. The only thing I
> > receive is an EJBException, which is rather ok, since the there was a
> > java.sql.SQLException thrown after the container tried to make the container
> > persist. I think this is a correct behaviour since the container can by no
> > mean distinguish beetween a failure and that the integrity is being
> > violated.
> >
> > My question is two fold:
> >
> > 1- First of all, how can I get a DuplicateKeyException instead of an
> > EJBException?
>
> I don't known any solution. I explain ....
> In case of entity with container-managed persistence, the problem
> is to have the code of the container independant of the type
> of the DataBase (Oracle, InstantDB, ...).
> Indeed, to day, the 'error code' of the java.sql.SQLException
> is database vendor specific, and so we are not able to know if
> the SQLException throwed by the insert SQL statement corresponds to
> a 'DuplicateKeyException' or to any others problems.
>
The container should do a findByPrimaryKey on the Primary Key got after
the
ejbCreate execution,
but before trying to insert the object in the DataBase. If the Object
exists, then
it could throw a javax.ejb.DuplicateKeyException.
It looks feasible. Moreover, I would expect that the specification
mandates this.
>
> That's why, the container always throws the EJBException !!
>
> >
> > 2- How can I get rid of the stack trace of the java.sql.SQLException that
> > JONAS prints? I tried to change the setting of the jonas.properties file so
> > that the jonas.trace.level parameter is set to none. No effect at all! I
> > still have this dirty stack trace.
> >
>
> This trace is done to be EJB specification compliant !!
> Indeed, in the 'Exception handling' chapter of the EJB
> specification 1.1, specify that the container have to log the
> exception or error so that the System Administration is alerted
> of the problem.
>
> I'm sorry not having constructive reply.
>
> Kind regards.
> Hélène.
> --
> -=- Hélène JOANIN -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
> mailto:[EMAIL PROTECTED] http://www-frec.bull.com
> Phone: 33.4.76.29.73.53 Fax: 33.4.76.29.76.00
> Download our EJB Server JOnAS at http://www.bullsoft.com/ejb
> _______________________________________________________________
> ----
> 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".
----
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".
