Tonny,
I totaly agree with you, simple question but the answer is not obvious.
Other people are trying to solve this issue.
http://www.jboss.org/file-access/default/members/jbosscache/freezone/
docs/2.2.0.GA/userguide_en/html_single/index.html#d0e2025
Invalidation :
http://www.jboss.org/file-access/default/members/jbosscache/freezone/
docs/2.2.0.GA/userguide_en/html_single/index.html#d0e2206
Stephane
Le 3 sept. 08 à 08:24, Tonny Staunsbrink a écrit :
Interesting problem, my solution to the problem is: "don't".
Keeping multiple data stores in sync is a pain. It is in WO as is
in in any other distributed environment - for example database
clusters. The challenges are so numerous that i consider sharding a
better solution for load balancing.
In the WO case, if we need fresh data we refresh them from the
database or use optimistic locking when it becomes vital that state
in the DB is the same as the state we operated on in the application.
Cheers
Tonny
On Wed, Sep 3, 2008 at 6:56 AM, Stephane Guyot
<[EMAIL PROTECTED]> wrote:
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/mezz.dk%
40gmail.com
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]
