No Subject

So, Yes, you can distribute it.  You could also link to it.  It doesn't
look like you can distribute just the interfaces.

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

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.

>> 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 can't access fields,
only methods (you can work around this with getter and setter methods).

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.

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

Thank you very much for the comments,

\x/ill            :-}

• Prev by Date: Re: New User Queries
• Next by Date: Proxy problem
• Prev by thread: Re:
• Next by thread: Great!
• Index(es):
  • Date
  • Thread