Hi all
I have spent the Christmas and New Year's holiday reviewing this issue with XMLUI.
I use XMLUI for 4 years and it has never presented a bug like this with hanging connections before the merge with DSpace code.
By that time besides the necessary modifications for maven Scott Phillips did some reorganizing of the code he felt necessary.
Around DSpace 1.5.0 or 1.5.1 I went crazy hunting idle connections that would take the site off the air and even tried some scripts to kill these connections without success.
Around 1.5.2 Mark Diggory did some changes in the code that stopped the hanging connections issue. But then we began getting an error like "This connection has been closed" that still happens today but not so often.
some comments:

1_before the merge with dspace there was a class DSpaceResourceManager responsible for closing the requet used by the aspects.
this class was in the aspects.xmap just before serializing:
        <map:pipeline internal-only="yes">
            <map:match type="AspectMatcher">
                <map:select type="parameter">
                    <map:parameter name="parameter-selector-test" value="{aspectID}"/>
                    <map:when test="0">
                        <map:transform type="PageNotFound"/>
                        <map:serialize type="xml"/>
                        <map:mount uri-prefix="{prefix}" check-reload="" src="{aspect}"/>       
            <map:generate type="file" src="protodocument.xml"/>
            <map:transform type="DSpaceResourceManager"/>
            <map:serialize type="xml"/>
this functionality has now been moved to DSpaceCocoonServletFilter but I think it is not running after the aspect chain is used.
I think the old way was working better and safer.

2_about the aspects:
Submission and Administration uses getDSContext().complete() in all functions
Eperson uses only a getDSContext().commit() in the functions as Scott Phillips suggests in his email.
Artifactbrowser does not use commit() or complete() but probably it does not change anything in the database.
In the case of eperson and artifactbrowser we still need a close() statement to free the connection.
I think we have to decide if the aspect should close or not the request.

3_if DSpaceCocoonServletFilter is working correctly I would change the completeContext() statement back to closeContext() because I think the aspects must be resposible for committing their changes not the filter.

I hope this helps solving these issues.
Paulo Jobim

On 22/12/2009, at 18:40, Scott Phillips (JIRA) wrote:

   [ http://jira.dspace.org/jira/browse/DS-383?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=10985#action_10985 ]

Scott Phillips commented on DS-383:

I believe this is a bug as well, the servlet wrapper should call context.abort() instead of commit..... but someone will need to track down any un-committed paths through the code. Each aspect should call a commit() before it passes on control to the next aspect. This way an error in a subsequent aspect won't roll back changes that successfully completed in previous aspects.

Auto commit functionality not working correctly in XMLUI

               Key: DS-383
               URL: http://jira.dspace.org/jira/browse/DS-383
           Project: DSpace 1.x
        Issue Type: Bug
        Components: XMLUI
  Affects Versions: 1.5.2
          Reporter: Robin Taylor
          Assignee: Mark Diggory

My understanding is that Dspace provides transactional processing by setting the database connection to auto-commit=false and doing a 'commit' once all processing has completed successfully. However, Manakin has a filter called  DSpaceCocoonServletFilter which contains the following code that runs after the request has been passed on for further processing...
  // Close out the DSpace context no matter what.
This appears to run, commiting changes to the database, even if an Exception is thrown in the main code.
The code needs to be more intelligent and only do a commit to the database where appropriate. The current catch-all approach causes problems in the event of a failure and also prevents any sort of multiple items upload, eg from a reference manager.

This message is automatically generated by JIRA.
If you think it was sent incorrectly contact one of the administrators: http://jira.dspace.org/jira/secure/Administrators.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

This SF.Net email is sponsored by the Verizon Developer Community
Take advantage of Verizon's best-in-class app development support
A streamlined, 14 day to market process makes app distribution fast and easy
Join now and get one step closer to millions of Verizon customers
Dspace-devel mailing list