2 Replies Latest reply on Mar 27, 2006 8:12 AM by Henrik Johansson

    Transaction question

    Henrik Johansson Newbie


      is it possible to use transaction annotations on a method of a SFSB to make it to not be part of the transaction?

      The thing is I've got a login functionality that has some built in security that prevents login calls for 24 hours for a user that has failed to login more than X times in a row. If anything goes wrong in the login method, the transaction rollbacks the modified data as it should. But for when the user has submitted the wrong password for the username an integer should be incremented and a date for the last failed login should be filled in and written to persistance storage (db).

      As an application exception is thrown from the login method the integer and date fields are never filled in due to the transaction rollback.

      As I see it now, the only possible (horrible) solution is to make the client (web app) trigger the writing of the incremented data after receiving and interpreting the exception. Yikes. There has to be a better solution.

      Am I forced to use Bean Managed Transactions?


        • 1. Re: Transaction question
          Emmanuel Bernard Master

          Call a submethod using @TransactionAttribute(TransactionAttributeType.REQUIRES_NEW)

          • 2. Re: Transaction question
            Henrik Johansson Newbie

            Thanks Emmanuel!

            The structure of the code is as follows:

            A SSFB named UserBean receives the call and passes it from the login method to its increaseFailedLogins method if needed. Here the call is interpreted and passed forward to the update method of either the PersonBean or the CompanyBean (both SLSB:s).

            It works if - and only if - i annotate the update method of the SLSB:s, i.e. it does not work when annotating only the increaseFailedLogins method of the SFSB because then the values are rollbacked anyway, somehow. (annotating with TransactionAttribute(TransactionAttributeType.REQUIRES_NEW))

            Is this the expected behavior? I would appreciate if annotating the increaseFailedLogins method was enough due to reuse of the SLSB:s, but this is good for now.