> But to get this right, when the application exception would be catched in a > service or decorator as mentioned in the email then no rollback should occur ? > And we always get an InvocationTargetException and not the thrown exception, > but > I guess is an was issue to.
The decorator doesn't know anything about EJB transactions thus it should have no impact on the rollback. I think it's more an ejb container related question. You can think about EJBs like being managed POJOs (like CDI beans) which automatically come with a few interceptors, mainly @Transactional and @JaasSecured (just to give them an arbitrary name). Thus you have the following call stack: * Your code which calls -> YourEJB* @JaasSecured on YourEJB (defined in CDI that all interceptors get called before the decorators) * @Transactional on YourEJB(defined in CDI that all interceptors get called before the decorators) * YourDecorator * YourEJB#someMethod() Thus if you catch any Exception in YourDecorator, the internal @Transactional from YourInnerEJB should not do anything special. It should not affect the whole behaviour at all. (still not sure if I fully got your scenario) LieGrue, strub ----- Original Message ----- > From: Thomas Herzog <[email protected]> > To: [email protected] > Cc: > Sent: Friday, March 22, 2013 10:05 AM > Subject: AW: WG: Transaction Rolled back in decorator or service even > exception is catched > > @mark > > The problem is that we are bound to WAS 8.0.0.1 because of this CORBA bug. > https://www.ibm.com/developerworks/forums/thread.jspa?threadID=415584 > which does not occur in WAS 8.0.0.1 but in all next releases. > We have EJB 1.1 which are getting migrated to EJB 3 in the next months, after > that we will switch to the newest version of WAS. > > A college of mine has WAS 8.5 and I will test it there. > > But to get this right, when the application exception would be catched in a > service or decorator as mentioned in the email then no rollback should occur ? > And we always get an InvocationTargetException and not the thrown exception, > but > I guess is an was issue to. > > Mit freundlichen Grüßen > > Thomas Herzog > Softwareentwicklung > > curecomp Software Services GmbH > Hafenstrasse 47-51 > 4020 Linz > > web: www.curecomp.com > e-Mail: [email protected] > tel: +43 (0)732 9015-5563 > mobile: +43 (0)664 8867 9829 > > > > > > -----Ursprüngliche Nachricht----- > Von: Mark Struberg [mailto:[email protected]] > Gesendet: Freitag, 22. März 2013 09:38 > An: [email protected] > Betreff: Re: WG: Transaction Rolled back in decorator or service even > exception > is catched > > > > Hiho! > > > Afaik WAS-8.0.0.x uses owb-1.0.1 with a few selected bugfixes which got > backported. > > We have fixed quite a few issues which could cause this behaviour in later > owb > versions. > > > Do you have access to the latest WAS-8.5.0.x for running the test? Or at > least > upgrade to WAS-8.0.0.2. > 8.0.0.1 is known to have quite some issues. > > > LieGrue, > strub > > > PS: seems to be a quite common pattern to use DeltaSpike cdictrl with openejb > for testing if WAS is used in production - have the same setup for a few > customers, and they are happy to have some tests now ;) > > > >> ________________________________ >> From: Thomas Herzog <[email protected]> >> To: [email protected] >> Sent: Friday, March 22, 2013 8:08 AM >> Subject: WG: Transaction Rolled back in decorator or service even exception > is catched >> >> >> Hi guys >> >> I have the following problem. >> >> I have a EJB service which is decorated. >> This decorator calls another EJB service and catches its thrown Exception > (RuntimeException annotated with @ApplicationException(rollback=”true”)). >> I get an InvocationTargetException, that’s the first catch. But the > transaction is marked a rollback only even the exception is catched. >> If I have a ejb service method which catches the thrown exception within the > service method and here the same issue occurs. >> >> The EJB service are annotated with: >> @Stateless >> @TransactionManagement(TransactionManagementType.CONTAINER) >> @TransactionAttribute(TransactionAttributeType.REQUIRED) >> >> EJB Service method (Saves an assignment): >> >> @Override >> publicCarrierHasCompanyCategoryEntry > saveCarrierToCustomerAssignment(CarrierHasCompanyCategoryEntry assignment) { >> > carrierDataAccessLocator.getCarrierDataAccess().checkForExistingCarrier(assignment.getId().getCarrierId()); >> returndataManager.merge(assignment); >> } >> >> Decorator (checks for exisiting assignment, to determine which event shall > get fired): >> >> @Override >> publicCarrierHasCompanyCategoryEntry > saveCarrierToCustomerAssignment(CarrierHasCompanyCategoryEntry assignment) { >> Boolean active = null; >> Boolean newAssignment = null; >> >> >> // Get active value of existing assignment / CarrierDateAccess is > annotated with @Stateless >> try{ >> CarrierHasCompanyCategoryEntry assignmetDB = > carrierDataAccessLocator.getCarrierDataAccess().checkForExistingAssignment(assignment.getId()); >> active = assignmetDB.getActive(); >> newAssignment = Booelan.FALSE; >> } catch(Throwable e) { >> // If throw the transaction will be rolled back >> e = ExceptionUtils.unwrap(e, InvocationTargetException.class); >> if(!(e instanceofAssignmentNotFoundException)) { >> thrownewCoreException(e); >> } >> } >> >> assignment = delegate.saveCarrierToCustomerAssignment(assignment); >> >> // If new assignment has been created >> if(newAssignment) { >> > assignedToCustomerEvent.fire(newCarrierAssignedToCustomerEvent(assignment)); >> } >> // If assignment has been updated >> else{ >> // If state has been changed >> if(!active.equals(assignment.getActive())) { >> if(assignment.getActive()) { >> > carrierActivatedEvent.fire(newCarrierActivatedEvent(assignment)); >> } else{ >> > carrierDeactivatedEvent.fire(newCarrierDeactivatedEvent(assignment)); >> } >> } >> } >> >> returnassignment; >> } >> >> Here I face the same issue (@Stateless): >> >> @Override >> public User generateDefaultAdminUser(final Carrier carrier) { >> final Carrier carrierDB = > coreDataAccessLocator.getGenericDataAccess().byId(Carrier.class, > CarrierNotFoundException.class, carrier.getId()); >> final SecureRandom random = new SecureRandom(); >> String username = null; >> String password = null; >> >> // Check for already existing user credentials >> for (int i = 0; i < 5; i++) { >> try { >> username = RandomStringUtils.random(MIN_PASSWORD_LENGTH, 0, > 0, Boolean.TRUE, Boolean.TRUE, null, random); >> password = RandomStringUtils.random((2 * > MIN_PASSWORD_LENGTH), 0, 0, Boolean.TRUE, Boolean.TRUE, null, random); >> > carrierDataAccessLocator.getUserDataAccess().getUserByUsername(username); >> if (i == 4) { >> throw new InternalErrorException("Could not > generate the usernamee and password for the admin user 5 times in a roll > !!!"); >> } >> } catch (UserNotFoundException e) { >> break; >> } >> } >> >> User user = new User(); >> user.setAdimn(Boolean.TRUE); >> user.setCarrier(carrierDB); >> > user.setContact(dataManager.merge(carrierDB.getDefaultContact().clone())); >> user.setEnabled(Boolean.TRUE); >> user.setLastPasswordChangeDate(Calendar.getInstance()); >> user.setUsername(username); >> user.setPassword(password); >> >> return dataManager.merge(user); >> } >> >> The funny thing is that the test with deltaspike-cdi-ctrl, openEjb and > openwebbeans do work. >> Is that a bug in webspehere embedded openwebbeans ? >> >> TestLibs: >> deltaspike-cdictrl-api-0.3-incubating.jar >> deltaspike-cdictrl-openejb-0.3-incubating.jar >> openejb-lite-4.5.1.jar >> was_public.jar >> >> Productive: >> Websphere 8.0.0.1 >> OWB version ? (ibm secret) >> >> For addition, we faced the issue that the decorated method must be the first > called on the delegate before any other method gets invoked, otherwise > decorator > chain will be broken. >> The second is that the thrown Exceptions are not unwrapped and will be > InvocationTargetExceptions. >> >> For now I solved it with an additional method parameter (Boolean) which > indicates that the assignment is a new one, so that the > AssignmentNotFoundException can never occur. >> >> Mit freundlichen Grüßen >> >> Thomas Herzog >> Softwareentwicklung >> >> curecomp Software Services GmbH >> Hafenstrasse 47-51 >> 4020 Linz >> >> web: www.curecomp.com >> e-Mail: [email protected] >> tel: +43 (0)732 9015-5563 >> mobile: +43 (0)664 8867 9829 >> >> >> >> >> >
