[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: object change notification

On Fri, 23 Jun 2000, Johann Romefort wrote:
> Hi Falko, Ann, and all ozonies,
> 
> What kind of notification would you like to do?
> I mean we could think about a notification on change,
> on delete, on new object creation, etc...
Yes.

> Here is how Jini Remote Events are working together
> with JavaSpaces. Here we could associate Ozone
> with the JavaSpaces cause they both are kind of
> repositories.
> 
> With JavaSpaces you can register a listener for a
> special type, with eventually some specified fields
> values, so when an Object matching this type and
> eventually the specified fields values is written into
> the repository, you can fire an event. Same for the
> delete approach. When an object is deleted from
> the repository, we can fire an event. I wont speak
> for notification on update cause...there is no update
> in Javaspaces ;-) Anyway the line of thought is the
> same. Now my question is, what kind of granularity
> should we put into this notification system (on object,
> fields?)
Object fields is not a good idea because ozone handles just object. It isn't
aware of fields and members. Of course, it would be possible to access the
fields via reflection but this would probably very slow.

> I dunno how JSDT handle remote events but
> I think an implementation in RMI wouldn t be too
> hard to do. We have to do such implementation for
> our JavaSpaces/Jini project but I dont know really
> when it would be done. What I can tell is that it will
> follow the Jini Specs.
Yes, the idea is clear. A handler for events like create, delete, update. The
questions is, how this could be actual implemented? (plug-ins or not? polling
of events or other solution? ...)

> 
> Anyway, Falko, would it be possible to have some
> kind of draft explaining in just a page or two the main
> architecture of Ozone, cause I really think that people
> needs something on which they can begin before
> hacking some code. My feelings are that people may
> be are scared to put their hands in an ODBMS because
> the name itself is scaring, and because of a lack of
> reference and standards.  I know you are busy, but just
> one page or two, or a beautiful schema :-)
Yes, yes, I know, Johann. This is the very next point on my to-do list.


Falko


> 
> Regards,
> 
> Johann
> 
> 
> 
> 
> ----- Original Message -----
> From: Falko Braeutigam <falko@softwarebuero.de>
> To: Ann Tecklenburg <tcklnbrg@promonium.com>
> Cc: <ozone-users@ozone-db.org>
> Sent: Friday, June 23, 2000 2:22 PM
> Subject: Re: object change notification
> 
> 
> > Ann, I Cc: this to the list. I hope this is okay.
> >
> > On Fri, 23 Jun 2000, Ann Tecklenburg wrote:
> > > Well, to some extent, JSDT adds a separate server
> > > to handle the object change stuff.
> > >
> > >  I suspect there is some overhead to assuming that every object is
> > > interested in being handled by the JSDT.
> > >
> > > So some thought must be given as to
> > > whether or not the JSDT should be at the core
> > > of Ozone so that all objects automatically get this
> > > feature or whether objects can merely be externally
> > > enabled for this feature, if desired.
> > The proposed plug-in architecture could be fine for this. A special
> plug-in
> > could integrate a JSDT based notification system. Maybe this could also be
> the
> > default notification system of ozone. However, other implementations could
> be
> > integrated very easy.
> >
> > > I can tell you for sure that few (none?) databases at any price
> > > have a change notification mechanism built-in.
> > Then let's do it!
> >
> > If anybody is real interested in contributing by writing a notification or
> > other plug-ins, then I could put the making of the plug-in system up on my
> > todo list.
> >
> >
> > Falko
> > --
> > ______________________________________________________________________
> > Falko Braeutigam                         mailto:falko@softwarebuero.de
> > softwarebuero m&b (SMB)                    http://www.softwarebuero.de
> >
> > l ozone database (using LocalDatabase)
> > >
> > >     for objects_number = 10,100,1000 do
> > >       create(objects_number, size)
> > >      read(objects_number)
> > >   destroy(objects_number)
> > >     end for
> > >
> > >     close connection
> > >
> > >   end for
> > >
> > >
> > >   But I think it isn't the correct solution.
> > Unfortunately you didn't send the complete code so I have to write my own
> to
> > check this ;) Anyway, I will do so. Maybe it's a good canditate for a new
> > test or sample.
> >
> > > If transactions that involve a change in the objects state, driven by
> the
> > > interface marked methods (with /*update*/), how can I manage
> transactions
> > > involving the creation and destruction of objects?.
> > The only way to create and destroy database objects are the API methods
> > createObject() and deleteObject(). These methods implicitely have WRITE
> lock
> > level. Does this answer your question?
> >
> >
> > Falko
> > --
> > ______________________________________________________________________
> > Falko Braeutigam                         mailto:falko@softwarebuero.de
> > softwarebuero m&b (SMB)                    http://www.softwarebuero.de
> >
-- 
______________________________________________________________________
Falko Braeutigam                         mailto:falko@softwarebuero.de
softwarebuero m&b (SMB)                    http://www.softwarebuero.de