Details

    • Type: Bug Bug
    • Status: Closed
    • Priority: Critical Critical
    • Resolution: Fixed
    • Affects Version/s: 2.1-dev
    • Fix Version/s: 2.1-dev, 2.1
    • Component/s: Persistence and DAO
    • Labels:
      None

      Description

      I tried writing a unit test to test OJB + Spring transactions.
      To my suprise, transactions are not starting.

      In fact, Im seeing some surprising results in mysql.log
      (yes Im using InnoDB), note no transactions, and the forced autocommit

      118 Query SET autocommit=1
      117 Prepare [1] INSERT INTO FOLDER...
      117 Execute [1] INSERT INTO FOLDER...
      117 Query SET autocommit=1

      It appears that OJB repeatedly sets autocommit=1
      and
      it never starts any transactions

      Here is my unit test, which tests out a new 'fake' API addPage to the PageManager. This API is temporary to test transactional behavior:

      public void testTx() throws Exception
      {
      Folder root = pageManager.newFolder("/");
      pageManager.updateFolder(root);
      Page[] pages = new Page[3];
      pages[0] = pageManager.newPage("/test1.psml");
      pages[1] = pageManager.newPage("/test2.psml");
      pages[2] = pageManager.newPage("/test3.psml");
      try

      { pageManager.addPages(pages); }

      In addPages, I try to force a rollback:

      public int addPages(Page[] pages)
      throws JetspeedException

      { System.out.println("Adding first page"); this.updatePage(pages[0]); System.out.println("Adding second page"); this.updatePage(pages[1]); System.out.println("About to throw ex"); throw new JetspeedException("Its gonna blow captain!"); }

      Finally, add pages is enabled for a Spring tx:

      <prop key="addPages*">PROPAGATION_REQUIRED,-org.apache.jetspeed.exception.JetspeedException</prop>

      1. Chatty.zip
        66 kB
        David Sean Taylor

        Activity

        Hide
        Ate Douma added a comment -

        Closed again now properly recorded against Fix Version 2.1 as well

        Show
        Ate Douma added a comment - Closed again now properly recorded against Fix Version 2.1 as well
        Hide
        David Sean Taylor added a comment -

        We've done a lot of testing on this issue over the last 6 months.
        I have no outstanding bugs on client bug tracking systems, so I will also resolve it here.

        Show
        David Sean Taylor added a comment - We've done a lot of testing on this issue over the last 6 months. I have no outstanding bugs on client bug tracking systems, so I will also resolve it here.
        Hide
        David Sean Taylor added a comment -

        MySQL logs for addPages operation under DB Page Manager

        Show
        David Sean Taylor added a comment - MySQL logs for addPages operation under DB Page Manager
        Hide
        David Sean Taylor added a comment -

        The unit tests are passing, rollbacks execute correctly in unit test, and the cache is now rolling back.
        I deployed to a Tomcat, and the rollbacks quit working. This had me stumped for a bit.
        Well interesting enough, it seems that a commit was getting in before my rollback, which tells me that OJB has some problem with ordering of DML.
        Where was the commit coming from?
        A very db-chatty implementation of the DB Page Manager, as it writes upon what I would expect to be read only operations.
        When we build the menus and tabs to be displayed for a page, there is an awful lot of database activity, including writes.
        It seems that these writes are atomic, and are forcing a commit on a shared connection with my test code (a portlet action) that executes the addPages API
        (see SiteBrowserPortlet.java, txTest() method)
        See attached chatty.log for database activity details
        Im leaving this open until I can figure out why the commit was slipping in before the rollback.

        Show
        David Sean Taylor added a comment - The unit tests are passing, rollbacks execute correctly in unit test, and the cache is now rolling back. I deployed to a Tomcat, and the rollbacks quit working. This had me stumped for a bit. Well interesting enough, it seems that a commit was getting in before my rollback, which tells me that OJB has some problem with ordering of DML. Where was the commit coming from? A very db-chatty implementation of the DB Page Manager, as it writes upon what I would expect to be read only operations. When we build the menus and tabs to be displayed for a page, there is an awful lot of database activity, including writes. It seems that these writes are atomic, and are forcing a commit on a shared connection with my test code (a portlet action) that executes the addPages API (see SiteBrowserPortlet.java, txTest() method) See attached chatty.log for database activity details Im leaving this open until I can figure out why the commit was slipping in before the rollback.
        Hide
        David Sean Taylor added a comment -

        Tried running the Page Manager's TestTransactions with the following changes:

        1. use this datasource

        <bean id="JetspeedDS" class="org.springframework.jdbc.datasource.DriverManagerDataSource">
        <property name="driverClassName"><value>com.mysql.jdbc.Driver</value></property>
        <property name="url"><value>jdbc:mysql://localhost/j2test</value></property>
        <property name="username"><value>j2</value></property>
        <property name="password"><value>ainttelling</value></property>
        </bean>

        2. added this bean to the configuration:

        <bean id="ojbConfigurer" class="org.springframework.orm.ojb.support.LocalOjbConfigurer"/>

        3. changed OJB settings

        ConnectionFactoryClass=org.springframework.orm.ojb.support.LocalDataSourceConnectionFactory
        ConnectionManagerClass=org.apache.ojb.broker.accesslayer.ConnectionManagerImpl

        And the transaction rolled back successfully (although the Page Managers cache was out of sync)

        Show
        David Sean Taylor added a comment - Tried running the Page Manager's TestTransactions with the following changes: 1. use this datasource <bean id="JetspeedDS" class="org.springframework.jdbc.datasource.DriverManagerDataSource"> <property name="driverClassName"><value>com.mysql.jdbc.Driver</value></property> <property name="url"><value>jdbc:mysql://localhost/j2test</value></property> <property name="username"><value>j2</value></property> <property name="password"><value>ainttelling</value></property> </bean> 2. added this bean to the configuration: <bean id="ojbConfigurer" class="org.springframework.orm.ojb.support.LocalOjbConfigurer"/> 3. changed OJB settings ConnectionFactoryClass=org.springframework.orm.ojb.support.LocalDataSourceConnectionFactory ConnectionManagerClass=org.apache.ojb.broker.accesslayer.ConnectionManagerImpl And the transaction rolled back successfully (although the Page Managers cache was out of sync)
        Hide
        David Sean Taylor added a comment -

        Just ran a test outside of Jetspeed on another Spring + OJB project here.
        Result: transactional commits and rollbacks work as expected
        So Im left wondering what we've broken here, as I was sure transactions were operational once upon a time.

        Im summing up the differences:

        – Datasource –
        other project: org.springframework.jdbc.datasource.DriverManagerDataSource
        Jetspeed : org.apache.jetspeed.components.rdbms.ojb.ConnectionRepositoryEntry

        – OJB.properties –
        other project: ConnectionFactoryClass=org.springframework.orm.ojb.support.LocalDataSourceConnectionFactory
        Jetspeed: ConnectionFactoryClass=org.apache.ojb.broker.accesslayer.ConnectionFactoryManagedImpl

        other project: ConnectionManagerClass=org.apache.ojb.broker.accesslayer.ConnectionManagerImpl
        Jetspeed: ConnectionManagerClass=org.apache.jetspeed.components.rdbms.ojb.ConnectionManagerImpl

        All other configuration files seem to be the same

        Show
        David Sean Taylor added a comment - Just ran a test outside of Jetspeed on another Spring + OJB project here. Result: transactional commits and rollbacks work as expected So Im left wondering what we've broken here, as I was sure transactions were operational once upon a time. Im summing up the differences: – Datasource – other project: org.springframework.jdbc.datasource.DriverManagerDataSource Jetspeed : org.apache.jetspeed.components.rdbms.ojb.ConnectionRepositoryEntry – OJB.properties – other project: ConnectionFactoryClass=org.springframework.orm.ojb.support.LocalDataSourceConnectionFactory Jetspeed: ConnectionFactoryClass=org.apache.ojb.broker.accesslayer.ConnectionFactoryManagedImpl other project: ConnectionManagerClass=org.apache.ojb.broker.accesslayer.ConnectionManagerImpl Jetspeed: ConnectionManagerClass=org.apache.jetspeed.components.rdbms.ojb.ConnectionManagerImpl All other configuration files seem to be the same

          People

          • Assignee:
            David Sean Taylor
            Reporter:
            David Sean Taylor
          • Votes:
            0 Vote for this issue
            Watchers:
            0 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved:

              Development