Kuali Rice Development
  1. Kuali Rice Development
  2. KULRICE-1243

Database cursor leaks caused by XAPoolDataSource

    Details

    • Similar issues:
      KULRICE-4431Maximum Open Cursors
      KULRICE-13339Attempting to run all the KEW unit tests will eventually cause "Maximum open cursors exceeded" errors to occur
      KULRICE-2079Move XAPoolDataSource from kns to shared module
      KULRICE-4957Update surefire plugin due to memory leak
      KULRICE-1187Maximum Open Cursors Exceeded
      KULRICE-13408Very large HistoryFlows cause Out Of Memory error.
      KULRICE-12338Very large HistoryFlows cause OOM error.
      KULRICE-1249Backport XAPoolDataSource fix from 0.9.1
      KULRICE-8970Memory leak errors when trying to shut down Tomcat
      KULRICE-8971Form classes cause unnecessary database IO because they are not @Transactional

      Description

      XAPoolDataSource implements our Lifecycle class but not Spring's InitializingBean. In the start() method we set the XAPool prepared statement cache to 0. However, when XAPoolDataSource is used from a spring file and the person using it forgets to set the init-method start will not be called and prepared statement caching will not be turned off. This is bad because it can cause a proliferation of open cursors, especially in large production environments, this was happening in Indiana University's implementation.

        Activity

        Hide
        Eric Westfall added a comment -

        I fixed this issue by having XAPoolDataSource not implement Lifecycle anymore but rather implement InitializingBean and DisposableBean. I also moved the setting of the prepared statement cache to 0 into the constructor for XAPoolDatasource. I went back through the code within the project and removed the init-method and destroy-method from any SPring instances of XAPoolDataSource. Lifecycle will now be handled via InitializingBean and DisposableBean.

        Show
        Eric Westfall added a comment - I fixed this issue by having XAPoolDataSource not implement Lifecycle anymore but rather implement InitializingBean and DisposableBean. I also moved the setting of the prepared statement cache to 0 into the constructor for XAPoolDatasource. I went back through the code within the project and removed the init-method and destroy-method from any SPring instances of XAPoolDataSource. Lifecycle will now be handled via InitializingBean and DisposableBean.

          People

          • Assignee:
            Eric Westfall
            Reporter:
            Eric Westfall
          • Votes:
            0 Vote for this issue
            Watchers:
            0 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved:

              Structure Helper Panel