[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: New User Queries
On Tue, 28 Dec 1999, Will Uther wrote:
> Again, thankyou very much for the response.
>
> > Is
> > com.sun.java.util.collections freely distributable? If yes, we include it
> > in the ozone distribution (or a link where to get it) and we are done
> > with ODMG.
>
> >From the license: "2. License to Distribute. Licensee is granted a
> royalty-fee right to reproduce and distribute the Software provided that
> .." (you don't change it, replace the copyright, etc. etc.)
>
> So, Yes, you can distribute it. You could also link to it. It doesn't
> look like you can distribute just the interfaces.
Hmmm... if we use our own implementation, then maybe we need the interface
files on compile time only? Sounds ok to me. If you only want to use
ozone/ODMG, then you only need the ozone package. If you want to recompile,
then you need Suns collection package.
>
> >>>> - If one DB 'object' calls a method on another DB 'object' what
> >>>> happens about locking, etc. Does this mean that Ozone has 'nested
> >>>> transactions' like the storedObjects ODBMS?
> >>
> >>> I answered this before: not each in-server call is one transaction. No,
> >>> ozone does not support nested transactions.
> >>>
> >>> If a read-only method is called, then a read lock is acquired. If this
> >>> method is marked "update", then a write lock is acquired too. ozone
> >>> uses pessimistic locking.
> >
> >> 2) you also cannot call an update method on
> >> another DB interface?
> >
> > I don't follow. It is possible to call another database object from
> > within an update method.
>
> Consider this:
>
> class CatImpl ... {
> void RunAway(Dog d) { // update method
> ...
> location = new Point(X, Y);
> ...
> }
> }
>
> class DogImpl ... {
> void isChasingCat(Cat c) { // not an update method
> ...
> c.RunAway(self());
> ...
> }
> }
>
> The method isChasingCat() does not change anything in the set of java
> obejcts hanging DIRECTLY from it. It does call an update method on another
> DB object though. Should isChasingCat() be declared an update method, or
> is it ok as written?
It's ok as written. Locks are aquired per database object. As well as changes
are commited per database object. That means, the DogImpl object gets a read
lock but the CatImpl object gets a read and a write lock. The write lock is
acquired just when the RunAway() method is called.
BTW: You need not to write self() as the argument of the RunAway call. Just
"this" is ok because ozone converts arguments automaticly. self() is the quick
(and dirty?) solution to call methods of the *same* object but within another
transaction level. For example calling RunAway from a read only method of
CatImpl.
>
> If all locks are acquired, and update marking occurs, when the INITIAL call
> is made then this code is incorrect. If further locks can be acquired then
> this code may be ok. I'm guessing that it isn't.
Locks are acquired while the transaction is running. The time difference
between acqiring read and write locks may cause deadlock problems but in OO
system (with late binding) there is simply no way to avoid this. The programmer
has to explicitely handle this by using the UPDATE lock level which is not yet
implemented in ozone.
>
> >> I agree the ODMG transaction system is easier. I'm in no rush for
> >> this... I'll wait for the ODMG stuff :).
> > IMHO your bidrectional communication model would bring back many of the
> > complexity that we want to hide from the programmer. So I will try to
> > provide explicite transaction demarcation as quickly as possible so solve
> > your problem ;)
>
> Please do not rush on my account. I have a ways to go before I need this
> functionality.
>
> >> In the ODMG spec as I understand it, you can store any 'persistance
> >> capable' classes in the database. These 'persistance capable' classes
> >> are made by post-processing normal classes. This seems similar to Ozone,
> >> except that Ozone has persistance-root classes, and those classes are
> >> only ever accessed through an interface. (ObjectStore manages this by
> >> processing any class that accesses a 'persistance capable' class, as well
> >> as the 'persistance capable' classes themselves.) Are you planning to
> >> have arbitrary class support in Ozone? Or are you going to keep the
> >> current limitation to an interface?
> > Proxies and the central activation architecture is a main idea behind
> > ozone. I do not want to change this and I don't see a good reason to
> > change this.
> >
> > Once we have ODMG support in ozone the programming of ozone will not
> > differ from the programming of ObjectStore. What do you mean by
> > "arbitrary class support"?
>
> In Ozone all the DB objects are accessible only through interfaces. This
> has at least two effects: i) all methods in an interface are public, you
> lose some data hiding capabilities of java and ii)
You do not have to put all methods in the public (database) interface.
> you can't access fields,
> only methods (you can work around this with getter and setter methods).
IMHO it's always not a good idea to access the fields of business objects
(database objects) directly.
>
> Actually, I think ObjectStore is similar in that it uses interfaces
> internally. My guess is that it processes the source files to produce
> interfaces with getter and setter methods to access the fields. To make
> sure these methods are used, it processes not only the DB objects
> themselves, but anything that accesses them.
I think this is one of the big advantages of our central activation over
decentral activation of ObjectStore.
>
> >> Personally, I think the Ozone system is a nice, clean solution - it's the
> >> same as Java's RMI mechanism. Limiting yourself to interfaces makes
> >> things less compatible with ODMG though.
> > Of course, the interface will be generated automaticly when the classes
> > are post-processed. (In fact, this is one of the bigger problems when
> > implementing ODMG support on top of ozone - but we already know how to do
> > it and we will do it ;)
>
> Will this planned processing support fields as well as methods? (As I
> descibed above?)
Creating getter/setter methods on demand seems to be a cool feature and it
should be no problem to add this. Other ideas on this?
Falko
--
______________________________________________________________________
Falko Braeutigam mailto:falko@softwarebuero.de
softwarebuero m&b (SMB) http://www.softwarebuero.de