Hi Dave,
thanks for bringing this topic up! After adding the event stuff I wanted
to let you know about it but the list archives have antispammed your email
address..
> How does the event notification support added in the most recent release of
> Cayenne work towards propogating changes to a DataObject to other user's
> DataContexts (as in the EO Framework in WebObjects)?
Currently, it does not provide such functionality automatically; howevery
you can wrap it yourself with very little code. The most important classes
are EventManager and EventSubject, I suggest you also look at its unit
test to see what it currently does and why. It's basically a clone of
NSNotificationCenter, but works a little different because of memory
management issues, Java events and general lack of selector-based method
invocation, but these are really secondary concerns. Basic usage is
simple: you make a class (e.g. your "session", whatever you use -
Tapestry?) implement EventListener, write the methods you want to register
(they have to take a subclass of java.util.EventObject as argument, in the
case of DataContext events that would be - surprise! - a DataContextEvent)
and then register an instance of this EventListener class with the
EventManager of choice, most likely the defaultManager(), which just
happens to be used by DataContext as well. When registering, it's
important to use the exactly same event "subject" as the sender; for this
reason EventSubjects should be created like it's done with
DataContext.WILL_COMMIT etc.; just refer to these and you are safe.
I'd appreciate it if you looked over the docs, source and unit tests and
provide some feedback, mention things that are unclear etc.; the machinery
works (it's used internally already) but we're taking baby steps.
> How can the ObjectStore get notification that the database has changed
> beneath it? This was one MAJOR problem with WebObjects' EOFramework: Any
> change made to the database outside of EOF was never recognized by the
> object graph.
This is an inherent problem with all systems that duplicate state (which
is exactly what a database client is). There are some ways to alleviate
this: simply merging data rows in optimistic locking scenarios when
possible, distributed cache coherency (like e.g. TopLink in multi-tier
mode) or - something that will establish itself further in the coming
years - RDBMS triggers that inform clients about specific changes. Oracle
is working on something like that (some people have rolled their own
versions since you can just write stored procs in Java), but this is a
'hard' problem: the last thing you want to do is naively notify, say, n
thousand clients about every little change in some table. Btw, contrary to
popular belief EJB CMP entity beans currently do NOT solve this problem.
One reason for the introduction of the current EventManager was laying the
groundwork for a distributed cache coherency mechanism, just like
mentioned above. Personally I'm eying JavaGroups as reliable group
communication mechanism; if you can contribute any ideas, requirements,
whatever - that would be great! You could also sponsor this effort with a
little $$$, which would certainly speed up the development. :-)
regards
Holger
This archive was generated by hypermail 2.0.0 : Tue Feb 11 2003 - 07:37:26 EST