Re: Invalidating objects asynchronously
Re: Invalidating objects asynchronously
- Subject: Re: Invalidating objects asynchronously
- From: Chuck Hill <email@hidden>
- Date: Wed, 3 Sep 2008 11:22:57 -0700
On Sep 2, 2008, at 1:55 PM, Sherry Tirko wrote:
We are seeing some similar issues and are also using
session().defaultEditingContext(). Can someone tell me what the
problems are with using the default editing context?
Unless you are doing some sort of change notifications or abusing EOF,
using the default EC will not cause exceptions. So, what is wrong with
using the default editing context for everything?
- if the data in the EC gets trashed, the user’s entire session become
useless. Unsaved changes and validation problems from one page need
to be cleared before something can be saved on a different page.
This is possible, but difficult to do consistently.
- unless you do a lot of refreshing fetches, the data the user sees
can be as old as (or older than) their session
- (this is more of a historical problem) large amounts of data
fetching into the default editing context will stay around much longer
than if each session creates many editing contexts
The best practice is to reserve the default editing context for read
only data that applies to the scope of the entire session.
Chuck
On Sep 2, 2008, at 12:57 PM, Dan Grec wrote:
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, and then Enumerate over the
results, a change notification can come in from another instance
and invalidate some of the objects we're currently Enumerating over.
The result is a NullPointerException.
Even when we deal with these with something like
if (item != null)
set.add(item.element());
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)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Webobjects-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden
--
Chuck Hill Senior Consultant / VP Development
Practical WebObjects - for developers who want to increase their
overall knowledge of WebObjects or who are trying to solve specific
problems.
http://www.global-village.net/products/practical_webobjects
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Webobjects-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden