[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: New User Queries
On Tue, 28 Dec 1999, Will Uther wrote:
> 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.
Ahhh, that's interesting. But does not change the situation for ozone. 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.
Afterwards we may add our own implementation for the reasons mentioned in the
last mail.
>
> >> - 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
In fact, it is possible to change the object but this changes will not be
persistent.
> 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.
>
> 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 :).
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
;)
>
> 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"?
>
> 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 ;)
>
> 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.
Not yet but I will check this.
Falko
--
______________________________________________________________________
Falko Braeutigam mailto:falko@softwarebuero.de
softwarebuero m&b (SMB) http://www.softwarebuero.de