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 (Webobjects-dev@lists.apple.com)
Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/webobjects-dev/
stephane.guyot11%40wanadoo.fr
This email sent to [EMAIL PROTECTED]
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Webobjects-dev mailing list (Webobjects-dev@lists.apple.com)
Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/webobjects-dev/archive%40mail-archive.com
This email sent to [EMAIL PROTECTED]
