1 2 Previous Next 22 Replies Latest reply on Dec 24, 2001 5:27 PM by guy_rouillier

    Transactional semantics of MBeans

    guy_rouillier

      > JUHA I AM THINKING ALOUD, since we whole chain of
      > invocation is today detached, it would be TRIVIAL to
      > string together the interceptors from the EJB model
      > to the JMX node, in fact all we need is a custom
      > "invoker" on the last interceptor of the chain (see
      > this?) where we would not have "beans" to speak of
      > but just the live pointer to the mbean (hence the
      > need for the registry here again and then the
      > containerinvoker just translates the MethodInvocation
      > in a dynamic invoke or the standard booboo if needed.

      The basic interceptor mechanism is in place, for standard mbeans its in the CVS, for model mbeans on my hard drive. I still don't see the need for your extra registry :D I didn't need it, as the flow in the interceptor stack is controlled either by the MBean server (in case of the standard mbean) which already has the live reference, or the Model MBean implementation (which also has the access to the live ref.)

      The empty shells for both security and log interceptors are in the CVS, they do nothing except delegate to the next interceptor, but all standard mbean invocations do pass through both of these already (as the stack configuration for standard mbeans is currenctly hard coded in JBossMX server).


        • 1. Re: Transactional semantics of MBeans

          > What are the transaction semantics of MBeans?

          They are not defined in the JMX spec.

          > In 2.4.3, there are no deployment descriptors, so I
          > can't set the commit option. Are database
          > connections for MBeans all container-managed?

          no.

          > Does it make sense to get the UserTransaction from an
          > MBean?

          yes, until a TxInterceptor for JBossMX is implemented at which point you can leave the tx demarcation to the mbean server Model MBean implementation to handle.

          • 2. Re: Transactional semantics of MBeans
            guy_rouillier

            Juha, thank you for the reply. As I mentioned, this is my first MBean, so please allow me to see if I am interpreting your response correctly. When you say that DB transactions in MBeans are not container managed, that means that I must explicitly manage them myself, correct? And rather than do this with a simple db.commit(), I should instead get the UserTransaction and do a tx.begin() and tx.commit()?

            • 3. Re: Transactional semantics of MBeans
              marc.fleury

              > Juha, thank you for the reply. As I mentioned, this
              > is my first MBean, so please allow me to see if I am
              > interpreting your response correctly. When you say
              > that DB transactions in MBeans are not container
              > managed, that means that I must explicitly manage
              > them myself, correct? And rather than do this with a
              > simple db.commit(), I should instead get the
              > UserTransaction and do a tx.begin() and tx.commit()?

              he is saying that EJB specifies a way for the container to start/commit based on tags, there are no such tags in the JMX spec. We might add it so that calls GOING TO the mbeans would be able to start stop a transaction. Other than that if your mbean is called from an EJB you can use the semantics of the EJB to leverage the transactions. EX: the mejb of jsr77 uses "transactions and security": from the ejb model to call mbeans. As I am sure you understand the connection accessed by your mbean is still enrolled in teh transactions (if you use our pools).

              juha's final point is that an interceptor, much like the EJB interceptor would need to be coded in there.

              JUHA I AM THINKING ALOUD, since we whole chain of invocation is today detached, it would be TRIVIAL to string together the interceptors from the EJB model to the JMX node, in fact all we need is a custom "invoker" on the last interceptor of the chain (see this?) where we would not have "beans" to speak of but just the live pointer to the mbean (hence the need for the registry here again and then the containerinvoker just translates the MethodInvocation in a dynamic invoke or the standard booboo if needed. THIS IS TRIVIAL and if your mbeans declares "Session Synchronization"??? VOILA! you are in the transactional mode and registered and notified and bla bla bla...

              juha this is truly powerful and would be orthogonal to jbossmx in fact it would be one of those specials EJB.

              Oh and of course because we are inside the JBoss VM the price to pay for this would be null. (no RMI). I am thinking this is a purely stateful implementation.... (allow for transactional inclusion).

              hmmm hmmmm hmmmmmmmmmm I like it :O
              marcf

              • 4. Re: Transactional semantics of MBeans

                > that means that I must explicitly manage
                > them myself, correct?

                correct.

                > And rather than do this with a
                > simple db.commit(), I should instead get the
                > UserTransaction and do a tx.begin() and tx.commit()?

                humm... that depends, whether the db connection is the only transactional resource you need to commit, or if there were other transactional resources participating in the transaction, in which case it should be managed by the Transaction Manager.


                • 5. Re: Transactional semantics of MBeans

                  > JUHA I AM THINKING ALOUD, since we whole chain of
                  > invocation is today detached, it would be TRIVIAL to
                  > string together the interceptors from the EJB model
                  > to the JMX node, in fact all we need is a custom
                  > "invoker" on the last interceptor of the chain (see
                  > this?) where we would not have "beans" to speak of
                  > but just the live pointer to the mbean (hence the
                  > need for the registry here again and then the
                  > containerinvoker just translates the MethodInvocation
                  > in a dynamic invoke or the standard booboo if needed.

                  The basic interceptor mechanism is in place, for standard mbeans its in the CVS, for model mbeans on my hard drive. I still don't see the need for your extra registry :D I didn't need it, as the flow in the interceptor stack is controlled either by the MBean server (in case of the standard mbean) which already has the live reference, or the Model MBean implementation (which also has the access to the live ref.)

                  The empty shells for both security and log interceptors are in the CVS, they do nothing except delegate to the next interceptor, but all standard mbean invocations do pass through both of these already (as the stack configuration for standard mbeans is currenctly hard coded in JBossMX server).


                  • 6. Re: Transactional semantics of MBeans
                    marc.fleury


                    > The basic interceptor mechanism is in place, for
                    > standard mbeans its in the CVS, for model mbeans on
                    > my hard drive.

                    Excellent, if we can keep the same tags for the transactional stuff as the EJB it will be clear.

                    > I still don't see the need for your
                    > extra registry :D I didn't need it, as the flow in
                    > the interceptor stack is controlled either by the
                    > MBean server

                    That is because you code the server you cretin ! ]:)

                    ANYONE doing work outside of it wants to see those components if you don't put it in the JMX we need to use JNDI and it's crappy QL (what ql?) or custom stuff to find it...

                    Stop "thinking", stop being an ungrateful little shit and just make the QL of jbossMX return the object **instance** or I am taking the next fucking flight to wherever it is that you are hiding and I make you regret the day you met me.

                    CAPICE?

                    marcf
                    (in case of the standard mbean) which
                    > already has the live reference, or the Model MBean
                    > implementation (which also has the access to the live
                    > ref.)
                    >
                    > The empty shells for both security and log
                    > interceptors are in the CVS, they do nothing except
                    > delegate to the next interceptor, but all standard
                    > mbean invocations do pass through both of these
                    > already (as the stack configuration for standard
                    > mbeans is currenctly hard coded in JBossMX server).
                    >
                    >

                    • 7. Re: Transactional semantics of MBeans

                      > or I am taking the next fucking flight
                      > to wherever it is that you are hiding and I make you
                      > regret the day you met me.

                      big bark, little bite :p

                      >
                      > CAPICE?

                      ei jummarra

                      show the code so I can see what you're talking about

                      ;)

                      • 8. Re: Transactional semantics of MBeans
                        marc.fleury

                        > show the code so I can see what you're talking about
                        >
                        > ;)

                        We are not alone, I am debugging something with the new stuff and I see

                        org.jboss.mq.server.MessageCache line 253

                        cacheStore = (CacheStore) getServer().invoke(cacheStoreReferenceName, "getInstance", new Object[] {}, new String[] {});
                        

                        looking up a reference means
                        1- a call to the mbean server (obscure)
                        2- to call a "getInstance" that is a call on the API.

                        Do you realize how redundant this is?

                        of course in the case above he coded JNDI non-serializable, in my case I just coded an extra org.jboss.system.Registry... that is just a map that supports lookups by anything (in our case the ObjectName)

                        in my case the above looks like

                        cacheStore = (CacheStore) Registry.lookup(cacheStoreReferenceName);
                        

                        What we are saying is that we can standardize it in JBossMX. Thinking about it now it is probably a bad idea as
                        1- it won't work with other vendors and would tie the stuff to jbossmx only ]:)
                        2- it works perfectly well as is with the Registry.

                        never mind :) we can do better without you, never mind


                        • 9. Re: Transactional semantics of MBeans
                          guy_rouillier

                          I see my messages were very long and required
                          scrolling left-right. I'll use the return key
                          in this one to form my own margins - you might
                          want to see if the jive folks would be willing
                          to wrap automatically.

                          Marc and Juha, thanks again. The only transactional
                          resource my MBean uses is a db connection from a
                          jbosspool, so I'll dispense with the UserTransaction
                          and just do a db.commit.

                          Also, I'd like to suggest JBoss use some mechanism so
                          that an MBean can manage its connections and
                          transactions independently of the EJB that calls it.
                          MBeans provide services, and should be standalone
                          components to the maximum extent possible. The EJB
                          may not use db connections at all; in my case, the
                          MBean is getting its own connection (from a
                          jbosspool), so that will be in a different
                          transaction scope than anything the calling EJB is
                          doing.

                          Hmmm, now I'm thinking out loud . Perhaps
                          some extension to the EJB transaction syntax would
                          work, if a logical way to specify can be found. I'm
                          thinking specificly of "independent". "RequiresNew"
                          terminates the existing transaction; wouldn't want
                          to do that. The MBean would use its own transaction
                          and let the EJB continue to use its own existing one.

                          "Uses" would be valid if the MBean could piggyback
                          on the EJB transaction (if it existed.)

                          • 10. Re: Transactional semantics of MBeans
                            davidjencks

                            I'm a little less certain than marc and juha appear to be ;-) that tm control over jca connections' transactions in mbeans will be so trivial. One reason declarative transaction management is more or less practical in ejbs is the prohibition of threads from ejbs. However, Guy explicitly said he is passing the db connection to a different thread. This might cause difficulties. For instance, the original method might return, thus committing the transaction, while the thread is still happily doing work. Sure sounds good for mbeans that don't start their own threads, though.

                            • 11. Re: Transactional semantics of MBeans

                              That's a very good point, David :)

                              yes this might be a bit more complicated than what it looked like at first.

                              well.. still would be cool for MBeans that don't spawn new threads for their transactions.

                              • 12. Re: Transactional semantics of MBeans
                                davidjencks

                                A couple of comments on Guys last post--

                                If we used the same interceptors for mbeans as we use for ejbs, we'd get the same choice of transaction semantics, for mbean calls through an interceptor chain (i.e.via invoke, not direct POJO calls to the actual object implementing the mbean). We'd have to extend out mbean metadata somehow to indicate the transaction semantics.

                                This definitely assumes the mbean doesnt' start its own threads-- if it does all bets are off.

                                I'm not sure what you mean by saying "RequiresNew terminates a transaction". When executing a RequiresNew method, the transaction previously associated with the thread is detached from the thread, and a new one is attached. When the method returns, the new one is committed or rolled back, and the original transacation is reattached to the thread.

                                This allows somewhat independent transactions, but note that the transactions in the RequiresNew method have to start after and end before the calling ejb's transaction.

                                Thinking about the original question a little more, I would expect that if you used a connection from a transactional pool, and the mbean was called from an ejb, and the ejb had a transaction going, the connection the mbean looked up would be enrolled in the transaction. In this case calling conn.commit() will mess up the container's transaction management. Setting up a ConnectionFactoryLoader with the NoTrans ConnectionManagerFactoryLoader should let you handle transactions yourself.

                                From your original post, how is the mbean being called? If not from an ejb method with a transaction, no commit makes sense. If from an ejb with a transaction, I'm surprised. Maybe the different thread is having an effect.

                                • 13. Re: Transactional semantics of MBeans

                                  We'd have to extend out mbean metadata somehow to indicate the transaction semantics

                                  Model MBean Descriptors is the mechanism to extend MBean metadata with semantic information.

                                  • 14. Re: Transactional semantics of MBeans
                                    guy_rouillier

                                    I think David may have answered the following question, but unfortunately I don't understand this stuff well enough to know for sure. I'm going to be terse here, but will gladly provide more details if necessary. We have an EJB (ejbA) which connects to a database (dbA) using a JBoss pooled connection, does a select and then closes the connection. I don't specify any transactional stuff in the deployment descriptor, so I'm using all defaults. ejbA then calls our MBean (mbA). mbA also connects to dbA using a connection from the same JBoss pool. The mbA reads and writes to dbA, then issues a db.commit(), which succeeds. Then mbA invokes ejbA recursively, which ends up calling mbA again. This time, when mbA does the db.commit(), it receives the following error:

                                    java.sql.SQLException: Cannot commit a transactional connection: See JDBC 2.0 Optional Package Specification section 7.1 (p25)

                                    Why does this work the first time through by not in the recursive call? If we remove the db.commit() from mbA, everything seems to work and get committed. But obviously I'd like to understand what is happening and how to implement it properly.

                                    1 2 Previous Next