Tynamo
  1. Tynamo
  2. TYNAMO-181

Implement DefaultJpaFederatedAccountServiceImpl

    Details

    • Number of attachments :
      1

      Activity

      Hide
      Dmitry Gusev added a comment -

      Patch implementing DefaultJpaFederatedAccountServiceImpl

      Show
      Dmitry Gusev added a comment - Patch implementing DefaultJpaFederatedAccountServiceImpl
      Hide
      Kalle Korhonen added a comment -

      Applied, thanks! The transaction should be active in merge() - do you have a use case where it's not? Also, persist() is semantically closer to INSERT.

      Show
      Kalle Korhonen added a comment - Applied, thanks! The transaction should be active in merge() - do you have a use case where it's not? Also, persist() is semantically closer to INSERT.
      Hide
      Kalle Korhonen added a comment -

      Keep open till I've incorporated this into a test application.

      Show
      Kalle Korhonen added a comment - Keep open till I've incorporated this into a test application.
      Hide
      Dmitry Gusev added a comment -

      It could be persist(), correct. I'm always use merge() for both insert/update, its a habit

      As for transaction – its inactive for my primary use case (I have the only use case actually – a simple sign-in web flow).

      Also, as far as I remember, even if transaction were active it will be rolled back at the end of request if not explicitly committed. Which means there should be @CommitAfter annotation somewhere or some other commit-logic which you normally won't have during simple login... but it may be present for some complex scenarios, I guess.

      Show
      Dmitry Gusev added a comment - It could be persist(), correct. I'm always use merge() for both insert/update, its a habit As for transaction – its inactive for my primary use case (I have the only use case actually – a simple sign-in web flow). Also, as far as I remember, even if transaction were active it will be rolled back at the end of request if not explicitly committed. Which means there should be @CommitAfter annotation somewhere or some other commit-logic which you normally won't have during simple login... but it may be present for some complex scenarios, I guess.
      Hide
      Dmitry Gusev added a comment - - edited

      I've updated for your changes, and its not working because of inactive transaction (new record doesn't appear in DB).

      I'm using:

      compile "org.apache.tapestry:tapestry-jpa:5.3.5"

      for JPA support

      Show
      Dmitry Gusev added a comment - - edited I've updated for your changes, and its not working because of inactive transaction (new record doesn't appear in DB). I'm using: compile "org.apache.tapestry:tapestry-jpa:5.3.5" for JPA support
      Hide
      Kalle Korhonen added a comment -

      See org.tynamo.security.federatedaccounts.base.AbstractOauthPage.java in federatedaccounts-core. The idea is that you use @CommitAfter on the page. If you are using AbstractOauthPage then the transaction is auto-committed if you haven't change the value of FederatedAccountSymbols.COMMITAFTER_OAUTH to false. DefaultJpaFederatedAccountServiceImpl is actually being used in the new federatedaccounts-test module and working.

      Show
      Kalle Korhonen added a comment - See org.tynamo.security.federatedaccounts.base.AbstractOauthPage.java in federatedaccounts-core. The idea is that you use @CommitAfter on the page. If you are using AbstractOauthPage then the transaction is auto-committed if you haven't change the value of FederatedAccountSymbols.COMMITAFTER_OAUTH to false. DefaultJpaFederatedAccountServiceImpl is actually being used in the new federatedaccounts-test module and working.

        People

        • Assignee:
          Kalle Korhonen
          Reporter:
          Dmitry Gusev
        • Votes:
          0 Vote for this issue
          Watchers:
          2 Start watching this issue

          Dates

          • Created:
            Updated:
            Resolved: