| 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 |