Apple

Dan,

interesting question and trouble ...

I have no clear answer but question that i hope may help you, see below.

Le 2 sept. 08 à 18:57, Dan Grec a écrit :

Hi everyone,

We're having an interesting problem in our apps, and I wanted to see if anyone else has solved it.

background:
We're not using page-based editing contexts. Everything (!) is in the session().defaultEditingContext().

I know, this is bad. We're working hard to fix this for our next release, but for the current release, we need to leave it how it is.

We are currently using our own ChangeNotification framework (based on the Wonder implementation from a couple of years ago) primarily because we deploy to J2EE application servers and want to use the internal JMS provider. This implementation listens for objectsChangedInStore notifications from EOF, and then sends out a message over the JMS provider. When the other applications receive the message, a running background thread invalidates any EOs with the global ID that was changed.

So, the problem.

When we access a relationship on an EO,

you take care of fault ?

and then Enumerate over the results,

how did you acquire the results, the collection ?

a change notification can come in from another instance and invalidate some of the objects we're currently Enumerating over.

Did you clone the collection before iterating ?

Modifying an Iterator while iterating it is not guaranteed to work, your trouble is not a Java Collection issue ?

The result is a NullPointerException.
Even when we deal with these with something like

if (item != null)
set.add(item.element());

item may not be null but item.element() may be.

What happens if another thread delete/add/refault one of the item, EO of relationship in the same time, in another thread.

When reading, acquiring the results, you may have N eos in the collection, but when enumerating any of the EOs in the collection may change

and modify the collection you are iterating over ( deleted, added and refaulted ).

HTH,

Stephane

it's still possible (and it happens) that the change notification slips in between the two lines.

So, one solution is to make change notification asynchronous, so they only happen when we're not currently serving a request.
The basic gist would be to check in application.handleRequest and sleep the thread if we are currently dealing with change notifications.

Once all the notifications have been dealt with, we can go on with serving requests.
Change notifications would never be processed while we are serving a request.

I don't particularly like the above solution, but we need something, and I've got nothing better.

(hopefully we can remove it when we move to page based editing contexts)
Does anyone see any problems with the above idea?

Thanks,
-Dan
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Webobjects-dev mailing list (email@hidden)

This email sent to email@hidden

References:
	>Invalidating objects asynchronously (From: Dan Grec <email@hidden>)
	>Re: Invalidating objects asynchronously (From: Stephane Guyot <email@hidden>)