8 Replies Latest reply on Nov 7, 2005 1:14 PM by Steven Mikumo

    jboss 3.2 to jboss 4.0 migration problem: requests executed

    fred Newbie

      Sorry but there was a problem with the title of my previous post that doesn't make it expicit.
      I add this one to give it a title.
      But you can respond here:

      http://www.jboss.org/index.html?module=bb&op=viewtopic&t=63325

      Sorry for the inconvenience,

      Fred

        • 1. Re: 3.2 to 4.0 problem: Optimistic locking whith tstamp
          fred Newbie

          I've realized my problem is perharps not linked to the commit time execution of request but with the optimistic locking management:

          In xdoclet, I've declared this stuff for the entity bean concerned:

          * @jboss.optimistic-locking
          * timestamp-column="TSTAMP"
          * field-name="tstamp"
          * column-name="TSTAMP"
          * jdbc-type="TIMESTAMP"
          * sql-type="DATE"


          I've checked my oracle9i database and it's really a DATE sql type.

          When I look at the request generated by the entity update:
          In jboss3.2, the where clause doesn't include the TSTAMP column condition and it works
          In jboss4.0, it includes the tstamp column and it crashes with the exception mentionned before.

          For information, everything is made through one transaction and nobody else is connected to this database at that moment. To my mind, it's not a concurrent access problem. But I've got an idea. The TSTAMP column is updated by a trigger automatically in the database when an insert or an update is done. Could it be possible that the entity bean does not load the tstamp value updated by the trigger?
          In that case, it would explain the error. But it leads to other questions:
          - why it wasn't the case in jboss3.2.2?
          - Is it possible to manage optimistic locking with a timestamp column managed by a trigger with jboss4

          Many thanks in advance,

          Fred

          • 2. Re: 3.2 to 4.0 problem: Optimistic locking whith tstamp
            Alexey Loubyansky Master

             

            "ffaure" wrote:
            In jboss3.2, the where clause doesn't include the TSTAMP column condition and it works


            Then optimistic locking didn't work?

            "ffaure" wrote:
            Could it be possible that the entity bean does not load the tstamp value updated by the trigger?


            Of course.

            "ffaure" wrote:
            In that case, it would explain the error. But it leads to other questions:
            - why it wasn't the case in jboss3.2.2?


            So far, it's not clear.

            "ffaure" wrote:
            - Is it possible to manage optimistic locking with a timestamp column managed by a trigger with jboss4


            No.

            • 3. Re: jboss 3.2 to jboss 4.0 migration problem: requests execu
              fred Newbie

              Hi Alex,

              Thanks a lot for your response, even if it means bad news for me...
              We have to change our optimistic locking management for all our applications (the problem is more for other applications that don't run under jboss...)

              However, I'm worrying because I just tried to remove the triggers on the tables, but the exception is still there!!!!!! How can it be possible?

              For more information, the entity bean concerned has "insert-before-postcreate" set to true because of relations and forein keys.
              Could it be linked to the problem? (If I remove this option, I've got another exception on missing foreign key...)

              About the changes between 3.2.2 and 4.0.1sp1, do you have any idea?
              Why some requests are delayed to commit time as they were not delayed before?
              Why these requests have not the same where clause:

              In ejb3.2.2: WHERE NUM_INTERNE_SITUATION=?
              In ejb4.0.1: WHERE NUM_INTERNE_SITUATION=? AND TSTAMP=?

              (with the same jar...)

              Thanks a lot in advance,

              Fred

              • 4. Re: jboss 3.2 to jboss 4.0 migration problem: requests execu
                fred Newbie

                More information:

                I've printed my tstamp info at ejbPostCreate time (juste after the insert request)
                Then, I've printed it too at ejbStore time. It is called just before the update that generates the exception.
                What is surprising me is that the values are equals!

                I have to ideas (with really no garanty):

                - there is a problem with the mapping datatypes (
                * jdbc-type="TIMESTAMP"
                * sql-type="DATE"
                )
                I tried with Oracle9i and Oracle8 mapping and I still get the exception...

                - there is a problem with the transaction: this update that is delayed to commit time (I still don't know why...) is not executed in the transaction context and then can't see the insert executed before. Is it possible? I think about it because in the log, I can see:
                "tx=TransactionImpl:XidImpl[FormatId=257, GlobalId=serge-dev/38, BranchQual=, localId=38] status=STATUS_NO_TRANSACTION;"

                The STATUS_NO_TRANSACTION is worrying me.

                Do you think I'm looking in the right direction?

                Many thanks in advance,

                Fred

                • 5. Re: jboss 3.2 to jboss 4.0 migration problem: requests execu
                  Alexey Loubyansky Master

                  Can you try a simple JDBC test? Insert a row using the same methods for timestamp parameters JBossCMP uses according to the type mapping you use and then try to query the table by the timestamp column and the value you inserted into it. This will tell you whether it's a type mapping issue or something else.

                  No transaction means the thread is not associated with an active transaction.

                  The SQL from 3.2.2 says optimistic locking is not used.

                  • 6. Re: jboss 3.2 to jboss 4.0 migration problem: requests execu
                    fred Newbie

                    Hi,

                    Alex, thanks a lot for your help.
                    I've been following your advises and it seems to be clearer for me.

                    The problem is that our tstamp column is a DATE column.

                    When I manually try an insert then an update with java.sql.Timestamp, it does not work. If I execute it with a java.sql.Date, it works but it doesn't save minutes and seconds info.
                    For a concurrent access management column, it is not so good.
                    I created another column with TIMESTAMP type (I'm on Oracle 9i) and it works fine with Timestamp.
                    I'm using the oracle ojdbc14.jar driver.

                    Do I have another solution than changing all my oracle tstamp column types?

                    Thanks in advance,

                    Fred

                    • 7. Re: jboss 3.2 to jboss 4.0 migration problem: requests execu
                      fred Newbie

                      Hi all,

                      We finally found a solution for our problem:

                      - we changed our timestamp columns from date type to timestamp type
                      - we changed the trigger to be effective only when a new timestamp value is not brought by the insert or update request itself:

                      CREATE OR REPLACE TRIGGER UPD_INS
                      
                      BEFORE INSERT OR UPDATE
                      
                      ON MY_TABLE
                      
                      REFERENCING NEW AS NEW OLD AS OLD
                      
                      FOR EACH ROW
                      
                      begin
                      
                       if :new.tstamp is null or
                      
                       :new.tstamp = :old.tstamp then
                      
                       :new.tstamp:=sysdate;
                      
                       end if;
                      
                      end;


                      It seems to be working. Did anybody already try this kind of stuff and do you see any problem related to this solution?

                      Thanks for your efforts,

                      fred