Hi Philippe,
Thank you for your prompt reply.
I have looked at the code in JOnAS and believe that the changes described below
would solve the problem. (This my first shot at at. I have not tried it out yet. I
just want to
make sure that I do not start implementing something which has its own problems
that
may be obvious to people much more familar with JOnAS than myself. Are patches
considered that have been submitted by users?)
1)
(a)The RequestCtx class should have a new field:
private Throwable appExc ;
with getter-setter methods.
(b) The setter methods for both sysExc and appExc should clear the other exception
field.
E.g. the setSysExc method would be rewritten as follows:
public void setSysExc(Throwable e) {
appExc = null ;
this.sysExc = e;
}
2)
The generated container classes should include a catch branch for each exception
thrown
by the bean:
catch ( <app-exception> appExc ) {
rtcx.setAppExc( appExc ) ;
throw appExc ;
}
where <app-exception> is a non-system exception appearing in the signature of the
bean
interface method (CreateException in the case of create()).
3) The following if block should be be added to the method
JEntityHome.postinvoke(RequestCtx rctx)
// Commit or Rollback transaction started in preinvoke
if (rctx.mustCommit()) {
+ if ( rctx.getAppExc != null && tm.getRollbackOnly() ) {
+ // rollback tx
+ try {
+ TraceEjb.error("Application exc. => Rollback the transaction.");
+ tm.rollback();
+ } catch (Exception e) {
+ TraceEjb.error("Exception during rollback:", e);
+ }
+ return ;
+ }
if (rctx.getSysExc() != null) {
Please, let me know your opinion as to wether the proposed patch would solve the
problem.
If not, why?. Are you aware of any new bugs the proposed patch would introduce? Is
point
2) difficult to implement?
Thank you
Peter
Philippe Coq wrote:
>
> Hi Peter,
> In fact the exception catched in the client depends on following
> factors:
> transaction attributes and persistence (explicit or implicit).
> In the following I describe the current behavior with JOnAS.
> 1) with a BMP Bean:
> 1-1 the create method runs with an unspecified transaction context
> (this case may happen with NotSupported, Never and Supports
> attributes):
> In this case the client receives the CreateException
>
> 1-2 the create method runs in the context of the caller's transaction
> (this case may happen with Required, Mandatory or Supports):
> In this case the client receives the CreateException
> 1-3 the create method runs in the context of a transaction that the
> Container started
> immediately before calling the ejbCreate method
> this case may happen with Required and RequiresNew attributes):
> In this case the client receives:
> java.rmi.RemoteException: Container cannot commit a transaction; nested
> exception is:
> javax.transaction.RollbackException
> this is what you have, and I agree that it is not conform to the
> spec.
> The problem is that at this time we have not found a solution to
> rethrow the application exception CreateException to the client,
> it is still
> an open bug.
>
> 2) with a CMP bean:
> in all the previous cases the client receives javax.ejb.EJBException
> because
> there is no standard way to test if a SQLException raised by a given
> JDBC driver
> correspond to the exception unique key constraint violation.
>
> we have to solve the problem 1-3 in a next version of JOnAS
> best regards,
>
>
> --
> Philippe
>
> Philippe Coq Evidian Phone: (33) 04 76 29 78 49
> Bull S.A - 1 rue de Provence - 38432 Echirolles Cedex France
> Download our EJBServer at http://www.objectweb.org
----
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".
