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:generate/>
<map:transform type="PageNotFound"/>
<map:serialize type="xml"/>
</map:when>
<map:otherwise>
<map:mount uri-prefix="{prefix}"
check-reload="" src="{aspect}"/>
</map:otherwise>
</map:select>
</map:match>
<map:generate type="file" src="protodocument.xml"/>
<map:transform type="DSpaceResourceManager"/>
<map:serialize type="xml"/>
</map:pipeline>
.....
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.
ContextUtil.closeContext(realRequest);
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
http://p.sf.net/sfu/verizon-dev2dev
_______________________________________________
Dspace-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/dspace-devel
------------------------------------------------------------------------------
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
http://p.sf.net/sfu/verizon-dev2dev
_______________________________________________
Dspace-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/dspace-devel
