@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 > > > > >
