John,
Excellent Question. Having been on the team that brought that code
into DSpace 1.5, I have rather intimate knowledge of this issue. We
do not recommend using a Event Consumer to directly manipulate the
Item in question by adding Bitstreams or altering its metadata
because not only is that available Contexts transactional window is
closed by the time you've reached processing the Event in the
consumer, but its difficult to predict the behavior or risk of
getting the Event System in the state of of an infinite event loop
because your alterations will in turn, also alter the Item and
generate new events in the process. The event system is best for
Consumers that do menial tasks like update the search index and which
do not return to the object model in memory and attempt alter it
again directly.
Unfortunately, this is the sort of task most folks were hoping the
Event System would solve in DSpace 1.5. I feel we are attempting to
address its shortcomings in the DSpace 2.0 roadmap to come up with a
solution.
If you do decide to attempt to use the Event System in such a manner
as to alter the Object in question and update it again, I would
recommend using a new dspace Context and make sure you can trap the
events in some sort of conditional check to make sure they should be
propagated to through your Consumer again. It will be challenging to
control the events continued propagation through the other consumers
present in the Event Manager/Dispatcher. The best I can advise you
is that in some cases you will get duplicate requests to update the
search and browse indexes.
Sincerely,
Mark
On Jun 18, 2008, at 4:31 PM, John Preston wrote:
Can someone say whether it is advisable or not to use the new event
system under 1.5 to add metadata or bitstreams to an item.
I am moving some of my code to event consumers that would add
metadata for various item types as well as add bitstreams based on
bitstreams already ingested. However I'm getting an exception when
I try to commit these additions within the consumer (either the
consume, end or finish methods). The particular exception is:
java.util.ConcurrentModificationException
at java.util.AbstractList$Itr.checkForComodification
(AbstractList.java:372)
at java.util.AbstractList$Itr.next(AbstractList.java:343)
at org.dspace.event.BasicDispatcher.dispatch
(BasicDispatcher.java:122)
at org.dspace.core.Context.commit(Context.java:286)
at org.ejamaica.server.dspace.DSpaceInstance.addSaying
(DSpaceInstance.java:1906)
at org.ejamaica.server.dspace.DSpaceInstance.updateSaying
(DSpaceInstance.java:1060)
at org.ejamaica.server.MyLibraryServiceImpl.myMethod
(MyLibraryServiceImpl.java:147)
Just for info. the section in my code that triggers the initial
context.commit() occurs in DSpaceInstance.java:1906.
If I don't commit after I add some metadata and/or bitstreams then
I don't get the error, but then the data and bitstreams don't
appear. If I even try and use the context.getDBConnection().commit
(); I get the same exception.
John
~~~~~~~~~~~~~
Mark R. Diggory - DSpace Developer and Systems Manager
MIT Libraries, Systems and Technology Services
Massachusetts Institute of Technology
Home Page: http://purl.org/net/mdiggory/homepage
-------------------------------------------------------------------------
Check out the new SourceForge.net Marketplace.
It's the best place to buy or sell services for
just about anything Open Source.
http://sourceforge.net/services/buy/index.php
_______________________________________________
DSpace-tech mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/dspace-tech
