Announcement

Collapse
No announcement yet.
X
  • Filter
  • Time
Clear All
new posts

  • Transactions not committed (JPA datasources)

    Hi there,

    I'm updating an application from SmartGWT version 3.1 to 12. The DataSources are based on JPA with BMT, the application is deployed in WildFly 14 using hibernate for persistence.

    Using version 12, read operations are working fine and the data is displayed in the GUI, but unfortunately, insert- and update-operations are not working anymore.
    The SQL-log on the server side shows no obvious error, the SQL insert-statements are visible in the log. It seems that the transaction is not committed after the RPCManager/DSRequest is finished.
    There is just an error from the container after the entity manager is released:
    12:24:58,316 DEBUG [com.isomorphic.jpa.JPADataSource] (default task-2) Releasing entity manager.
    12:24:58,317 ERROR [org.jboss.as.txn] (default task-2) WFLYTX0003: APPLICATION ERROR: transaction still active in request with status 0

    I could reproduce the behavior also with the JPADS sample using BMT or LMT using a simple table.
    I also checked the updates on the JPA-integration documentation page, but could not find any major configuration changes.
    Is the callback that is supposed to commit the transaction missing or not executed? (I could not find any further information about additional configuration on the RPCManagerCompletionCallback- or the Committable-Interface)

    Many thanks,
    Daniel

    SmartClient Version: v12.0p_2019-01-15/Pro Deployment (built 2019-01-15)

  • #2
    This sounds like an issue, although to be sure what's going on we need more information. If this is indeed internal issue, additional info would help to reproduce and fix it, and if it's not, we still need to know more to help you. At the moment we can't reproduce it.

    So, ideally we would like you to create a standalone test case showcasing the issue. It would be better if you could keep it as minimal as possible, like single DS (as you've already mentioned) and pure SC (or SGWT) client code executing simple call to add a record (or whatever operation is failing to commit transaction). We'd prefer a scripted use case, but in case if user actions are needed (like click a button, enter some data, etc), then detailed instructions are also needed. It'd be great to see all definitions and code involved as well as complete server log with DEBUG log level enabled for these categories: com.isomorphic.datasource.DSTransaction, com.isomorphic.jpa.JPADataSource and com.isomorphic.datasource.DSRequest.

    Thank you.

    Comment


    • #3
      Hi there,

      After your comment, I tried to reproduce the problem using the included smartclientSDK showcase on my localhost by adding a new record in the JPA Many-to-One demo.
      The insert statement is visible in the log, but there is no DB commit in the log and the "inserted" data is not available after a reload or restart (all JPA-showcases hang after this action on my environment :( ).
      I would have expected a "Committing current transaction." or "Committing transaction for queued operation(s)." log entry from the JPADataSource.

      Could that be the same issue or is this behavior intended?

      Any help on this is appreciated.

      Thank in advance, Daniel

      Comment


      • #4
        Well, something must be different on your side, cause this is still not reproducible for us.

        We did try to mimic exact way user would do it:
        1. download 12.0 nightly build Jan 15 (exact same version as yours)
        2. in smartclientSDK executed ./start_embedded_server.command (Mac)
        3. loaded Many-to-One sample.
        4. added new record and saved it.
        5. added one more and saved it as well. (showcase responding, no hanging)
        6. reloaded page and new records were still there.
        7. Meanwhile in terminal logs showed completely normal execution flow, i.e. transactions were started and committed before releasing EntityManager.

        NOTE we repeated same steps for the very latest 12.0 nightly build (Feb 7) and it also worked fine.

        Could you think of anything that you did differently than described above?
        If you do the same and it still not works for you, could you share complete server logs?

        Comment


        • #5
          After some further testing and debugging, could this be a problem with the pro edition?
          I cannot reproduce the error using the showcase of the nightly full-featured evaluation edition, just with the pro edition.
          When I step through the code using my IDE, I see that the commit in the full-featured edition is triggered by the complete() method of the DSTransaction in the isomorphic_core_rpc.jar.
          In the pro-edition this method seems be "empty"?

          Comment


          • #6
            Hi daniel.bacher,

            there definitely is some difference between Pro and Power. I remembered seeing it here. Rest is for Isomorphic to answer.

            Best regards
            Blama

            Comment


            • #7
              As the link that Blama posted points out, Automatic Transactions are not a feature of Pro Edition, but of Power and above.

              Comment


              • #8
                Thank's for your replies. I am updating from pro 3.1 to 12 and did not expect a change in this as I am using "just" JPA-datasources.
                (As I mentioned above, the issue seems to be also in the showcase for JPA (pro version))
                Last edited by daniel.bacher; 11th Feb 2019, 04:35.

                Comment


                • #9
                  There's never been a change in the license policy - Automatic Transactions were never part of the Pro license, from the first version the feature was introduced.

                  If you see transactions being committed in 3.1, it's possible that you are actually using .jars from an evaluation copy rather than your licensed Pro .jars.

                  Comment


                  • #10
                    Hmm, ok. I will contact you for updating the licence, thx.

                    Comment


                    • #11
                      Just for my better understanding, that means that using the pro edition I cannot use JPA to create or modify a record as the JPA datasource will not commit the transactions?
                      The JPA samples in the showcase all hang in the pro version after adding or updating a record (but only the filter sample has a note requiring the SmartClient Power Edition).

                      Comment


                      • #12
                        No, what you should see is that transactions are not initiated, hence there is no need to commit them. If thatís not what youíre seeing you may still have some kind of mixed jar setup.

                        Comment


                        • #13
                          I tried with a clean download of SmartClient_v120p_2019-02-09_Pro.zip (again) using the provided embedded_server, not my application. Just tried to add a record in the JPA sample, that's why I was asking.
                          (Btw. I checked my old version where it was working and the the entries in the Manifest files show "Isomorphic-SmartClient-Version: SNAPSHOT_v8.3d_2012-07-26Pro, Isomorphic-SmartClient-Package-Date: 2012-07-26", I think these are the licensed Pro .jars. A short debugging session shows that there was no DSTransaction in 2012 and there was an "onSuccess" by the RPCManager. :))
                          Last edited by daniel.bacher; 11th Feb 2019, 16:05.

                          Comment


                          • #14
                            OK, an engineer has been assigned to look into this. We'll post back on this thread when we know more.

                            Thanks,
                            Isomorphic Software Support

                            Comment


                            • #15
                              There was indeed an issue with Pro-licensed builds with JPA, but it has now been corrected.

                              Just to reiterate: the Automatic Transactions feature, which groups together multiple DataSource operations into a single transaction, is not a Pro license feature and has never been a Pro license feature. You may see terminology in the logs related to transactions, but this just indicates that a transaction is being used to commit each request *individually*, not that the Automatic Transactions feature is somehow active.

                              Comment

                              Working...
                              X