10 Replies Latest reply on Oct 17, 2019 8:46 PM by marklittle

    STM in Quarkus

    epbernard

      Hi there,

       

      Here are some quick comments based on my reading of https://quarkus.io/guides/stm-guide

       

      It's a bit unfortunate that the STM engine uses @Transactional (org.jboss.stm.annotations.Transactional) for tx object marking.

      In an IDE, it conflicts with Java's @Transactional (javax.transaction.Transactional).

       

      Since Quarkus is doing work at build time, we could reuse the Hibernate with Panache approach for STM and avoid the cumbersome passage to Interface and container for object creation. This needs to be fleshed out but it would be much clearer to get something like this

       

      FlightService fs = FlightService.stmInstance();

      //maybe also adding

      FlightService fs = new FlightService();

      ...

      fs.enableStm();

      //unless a new should always create a container.

       

      Note that this no longer has to be a an interface

       

      Then we could hide AtomicAction demarcation and reuse @Transactional (javax.transaction.Transactional) for user code demarcation.

       

      @Transactional

      public String processOrders() {

         Order order = Order.stmInstance();

         order.validate();

         order.process();

      }

       

      Would be equivalent to the current

       

      AtomicAction aa = new AtomicAction();

      Container<Order> container = new Container<>();

      OrderImpl instance = new OrderImpl();

      Order order = container.create(instance);

      aa.begin();

      {

          try {

              order.validate();

              order.process(); 

              aa.commit();

             

          } catch (Exception e) {

              aa.abort();

          }

      }

       

      Note that it's confusing to me whether STM applies to services or actual state object like beans? The doc mentions a FlightService but the Narayana doc seems to mention rather an Bean like object. I think we miss more real case usages or something that looks like a real case usage. Maybe you could write a Todo list managment example using STM.

      There is a lot we can do to make this much more user friendly.

        • 1. Re: STM in Quarkus
          tomjenkinson

          Regarding using javax.transaction.Transactional to demarcate STM transactional boundaries would be confusing to me as that is normally to specify the expectations of XAResources within it's scope are going to behave.

           

          When you click through an @Transactional in an IDE I would expect it could normally differentiate between two classes from different packages? Maybe I misunderstood what you are referring to with respect to conflict?

          • 2. Re: STM in Quarkus
            epbernard

            The #1 user we have had for a long time in Hibernate ORM is people using org.hibernate.annotations.Entity instead of javax.persistence.Entity.

            Until we deprecated it and removed it.

             

            So for LRS do you want also another demarcation approach? One per style of transaction? It feels to me as a user that you are pusing your incidental complexity over to me.

            • 3. Re: STM in Quarkus
              tomjenkinson

              Hi Emmanuel, I think I understand what you are saying in your HHH example (hibernate-orm/Entity.java at 5.3.13 · hibernate/hibernate-orm · GitHub ) as it seems that is designed to extend JPA Entity with some additional behaviour but the STM example seems different to me. In that case the STM Transactional interface is different because it is to demarcate STM transactions, whereas the JTA Transactional is to demarcate JTA transactions.

               

              In the Narayana implementation the transactions that back the interfaces converge at AtomicAction within arjunacore but this is a versatile base layer that is then customised for use in the higher level specialised transaction protocols. One specific example is that STM transactions do not have to (but may) have the durability property of ACID. Does that help?

              • 4. Re: STM in Quarkus
                epbernard

                Yes @Entity was overriding the main @Entity annotation. But that's not the point. The point was that people just auto-imported the wrong one with their IDE and things were not working as expected. I fear you have the same problem for your reuse of the "Transactional" type name (but from different packages). Or at least a risk.

                • 5. Re: STM in Quarkus
                  epbernard

                  To be clear, this is not me asking a question. It's more ideas to try and bring ease of use to STM. I came with these proposals while studying the subject. If you think they don't have merit, that's ok, you are the subject matter expert. But what I know is that as a user, this is not to the level of ease of use I am used to by frameworks nowadays.

                  • 6. Re: STM in Quarkus
                    tomjenkinson

                    I see, thanks for clarifying Emmanuel. Given the point I made about the differences between the two interfaces I don't think we would just remove the STM annotation in favour of the the JTA annotation.

                     

                    Regarding the name itself, I would note that there is precedent for different frameworks to share different primary class names - for example within the JDK we can see both a java.awt.List and java.util.List. mmusgrov do you have an opinion on a possibility to rename of the STM annotation. I would note that the Transactional interface name has existed as a public API for a while now: History for STM/src/main/java/org/jboss/stm/annotations/Transactional.java - jbosstm/narayana · GitHub  (looks like 2012 it was added into our repo).

                     

                    One thing I wondered, perhaps we just have to make sure in the examples and docs that they say @org.jboss.stm.annotations.Transactional - the guide you referenced as it stands does reference this interface in the text but the code snippet does not and perhaps that could be one route to make it easier when entered into an IDE?

                    • 7. Re: STM in Quarkus
                      mmusgrov

                      epbernard  wrote:

                      Since Quarkus is doing work at build time, we could reuse the Hibernate with Panache approach for STM and avoid the cumbersome passage to Interface and container for object creation. This needs to be fleshed out but it would be much clearer to get something like this

                      Let us investigate to see if the same approach makes sense for STM users.

                       

                      epbernard  wrote:

                       

                      Then we could hide AtomicAction demarcation and reuse @Transactional (javax.transaction.Transactional) for user code demarcation.

                       

                      AtomicAction demarcation is not required. The guide says that by default each method of the STM object will run with a transaction context (managed by the STM container). AtomicAction is included in the guide:

                       

                      • to clearly show the composability of transactional operations on memory
                      • to more closely align with other STM solutions that users may already be familiar with (eg Haskel uses the `atomically` keyword to demarcate atomic blocks)

                       

                      epbernard  wrote:

                       

                      Note that it's confusing to me whether STM applies to services or actual state object like beans? ... I think we miss more real case usages or something that looks like a real case usage. Maybe you could write a Todo list managment example using STM.

                      Good point. I used the word service since I wanted to encourage the use of STM in a microservice environment though I can see how it may give the wrong impression. In the next iteration of the guide we will look into improving the example along the lines that you suggest.

                       

                      epbernard  wrote:

                       

                      There is a lot we can do to make this much more user friendly.

                      I am not convinced but let me think more about this comment.

                      • 8. Re: STM in Quarkus
                        marklittle

                        Things to remember:

                         

                        - There's a full STM guide within Narayana which goes into more details than maybe the Quarkus guide does (though I've not checked the latter to be sure).

                         

                        - STM persistence could use Panache but they're not the same thing. Just as transactional POJOs could be written to use Hibernate for persistence or a flat file system or a high reliability in-memory data grid.

                         

                        - STM is about transactional (A, C and I, maybe D) objects; services can be built from those objects just as services could be built from EJBs.

                         

                        - STM doesn't need to have persistence. In fact most STM objects would be volatile in nature hence why "maybe D".

                        • 9. Re: STM in Quarkus
                          marklittle

                          OK I've gone through the Quarkus STM guide and can confirm it doesn't cover the STM work in the depth that the Narayana doc does.

                          • 10. Re: STM in Quarkus
                            marklittle

                            If the @Transactional annotation is a cause of concern there's no reason why we couldn't also add another new synonym annotation.