Sorry to bother you again, but quick question. When does the end() method
get called. Is it after the events arraylist has completed iterations of all
events. if so then I could move all my processing of the bundles,
bitstreams and items to this method. The only other thing I would have to
guard against would be more events of the same type, subject and object
with the same transaction ID.
This may be a wise thing to try, yes it is done after "consume" has
completed on all the events, the dispatcher is done with the list of events
at that point. most of the consumers actually do complete their processing
at this point too. But be careful of what I stated above, you need to make
sure this list of Events is coming from the correct Context.
On Wed, Jun 18, 2008 at 9:33 PM, John Preston <[EMAIL PROTECTED]> wrote:
> Ok, I think I understand what is happening. When I create or remove
> bundles, or bitstreams or any of these objects
> that generate events, these add new events which cause a concurrent
> modification conflict with the events arraylist, that is being used
> to dispatch the events in the first place. So having anew context will not
> help me. I need to bypass adding new events for any modifications.
>
> I think I have three choices, and your thoughts would be welcome on them.
>
> 1) Keep my code as mediafiletsr run periodically, and wait for 2.0;
> 2) extend the code for Bundles, Items, Bitstreams, etc, anything that
> issues events when the update() method is called, and add another
> update(boolean issueEvent) merthod that performs the database update
> with or without issuing any events, depending on the
> parameter passed;
> 3) implement my own event system;
>
> I'm leaning towards 2 or 3, but I don't know how many DSpace objects issue
> events. I'm playimg with a GWT front end application to some
> RPC services that actually interact with the dspace objects via the
> dspace-api codebase. It has gone pretty quickly up till this point so I'm
> looking for
> the quickest long lasting method.
>
>
I'd avoid (3). I think (2) will be coming in the DSpace 2.0 next year
sometime (we are still at the drawing board on this so its very early). If
you take this route and it isn't compatible with what gets done in our
development, it may be difficult to integrate. (1) Is your safest bet, but I
understand why you want to get away from it.
If you would, please forward a summary of this to the dspace-tech list as
a reply so that we have a complete thread there.
Cheers,
Mark
> John
>
>
> On Wed, Jun 18, 2008 at 7:26 PM, John Preston <[EMAIL PROTECTED]>
> wrote:
>
>> 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.
>>>
>> Yes, I saw that, that's why I started to use
>> context().getDBConnection.commit() to avoid infinite event loops.
>>
>>
>>> 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.
>>>
>> That would be great.
>>
>>
>>> 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.
>>>
>> I tried this but I still get the error. I did the following:
>>
>> Context c = new Context();
>> ctx.setCurrentUser(context.getCurrentUser());
>> ctx.setCurrentLocale(context.getCurrentLocale());
>>
>> I'll look again at the code in the morning to see if I can understand
>> where the problem lies.
>>
>> Thanks.
>>
>> John
>>
>>>
>>>
>>> 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
