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

Re: New User Queries

Thanks for the fast reply.

>>  I looked at the ozone
>> ODMG stuff in org.ozoneDB.odmg and it seems to use the JDK 1.2
>> collections. Did you know that there is a JDK1.2 compatible collections
>> library that works with JDK1.1 at http://java.sun.com/beans/infobus/
>> (down the bottom of that page)?  You should be able to make it work with
>> just a few switched import statements if you want to stay with java 1.1.
>> It is what the java 1.1 version of the ODMG spec uses.
> Thanks for the hint. But it seems that we will not use Java collections to
> implement ODMG collections.

I mentioned this for two reasons.  The first you answered.  The second is
that the ODMG 3.0 bindings seem to come in two versions.  The JDK1.2
version inherits from the JDK1.2 collection APIs in java.util.  e.g.

public interface DCollection extends java.util.Collection

The JDK1.1 version inherits from the collection APIs I mentioned above
which are in the package com.sun.java.util.collections.  e.g.

public interface DCollection extends
com.sun.java.util.collections.Collection

I think you might need that set of collection interfaces to release a
JDK1.1 compatible set of ODMG bindings even if don't use the sun
implementation.

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

So, a read-only method means two things: 1) you cannot change any of the
java objects you reference, and 2) you also cannot call an update method on
another DB interface?

Then in the next message... :)

>>   Is there any way to have a dialog between the server and the client
>> within a single transaction?  e.g. 
> Currently not. If you want to have code executed in the same transaction
> (using the current ozone interface) then you have to put the code in one
> database object method.
> 
> Once ODMG support is there you can mark transaction boundaries
> explicitely. I'm not yet sure if this is a win because in ODMG you MUST
> wrap every piece of code that interacts with the database in a
> try/commit/abort/rollback sequence. That is something that makes the code
> less readable, that is actually not needed, that makes the client side
> code depend on the database interface (ODMG), and that does not allow to
> use the same client side code for transient and persistent versions of
> the application. However, we are working on ODMG and we will hopefully be
> able to release a first version soon.
> 
> To fix these problem we will support the ODMG spec but keep the current
> ozone interface also. Do you guys think it's a good idea to get the
> possibility to mix both interfaces in the same code?

This mixture of interfaces sounds cool.  If you currently have an ODMG
transaction open then that is used, otherwise each method call is it's own
transaction.

>>   - Transaction start
>>     - client sends server some info
>>     - server sends client a request for more info
>>     - client sends requested info
>>   - Transaction end
>> 
>>   Would I have to implement an RMI object on the client side that I pass
>>   to the server?  This would then allow the server to get information
>> from the client by making method calls on the remote (client side)
>> object, right? Is there an easier way?
>
> I don't follow. The server never does remote calls on the client side. Is
> there a reason why you don't use something like:
> 
>	 start
>		 client calls database object
>		 (returned object contains request for more info)
>		 client sends requested info
>	 end

This would work fine for the ODMG interface.  For the current ozone
interface you couldn't do that though.  My thought was to introduce a way
to get the same effect as this, but without the ODMG interface.

If the client passed the server an RMI object in its interface call, then
the server could use that object to conduct a dialog with the client within
the transaction formed by the original client interface call.

I agree the ODMG transaction system is easier.  I'm in no rush for this...
I'll wait for the ODMG stuff :).

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?

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.

BTW, have you suggested Ozone's way to handling things to the Java
Standards group:
http://java.sun.com/aboutJava/communityprocess/jsr/jsr_012_dataobj.html?
Given its similarity to RMI they might be interested.

later,

\x/ill          :-}