Re: AW: AW: Fw: GPL / LGPL

Hello Wieslaw, hello Per,

as far as I understand now, the ozone database server works like this:

At any time there´s only one instance of a persistent object in memory. This 
object resides for the whole lifecycle at the server´s site. If a client 
invokes some method, this method-call is always (!) delegated to the server 
transparently. You generate some client-side stubs in a CORBA style fashion, 
which handle the client-server interaction.

The programmer has to differentiate between read-only and update methods. 
Therefore you have the /* update */ statement. Whenever a read-only method is 
invoked, the server acquires a read lock on the corresponding object. 
Whenever an update method is invoked, the server acquires a write/exclusive 
lock. If a server-side persistent object calls other methods of potentially 
other persistent objects, the corresponding locks are acquired in the context 
of the client-side transaction.

You can have multiple, concurrent readers but only one writer. If a write-lock 
is granted, every transaction has to wait for the object. If a read-lock is 
granted, other readers are welcome, but a writer has to wait until the object 
is released by everybody. The locks are released at the end of a transaction.

Do you grant subsequent read locks, if a writer is already waiting for an 
object, so that in fact a writer may wait indefinitely for an object, because 
there´s always a reading transaction? Or do you place lock requests in a 
queue?

What about timeouts and deadlocks?

What kind of server-side cross-transactional caching strategy do you have?
You place the (related) persistent objects in clusters, which are stored on 
disk at a size of 64 kbyte, am I right? You probably have some kind of index, 
so that you know, in which cluster you can find an object with a specific 
OID. At request time, you put the whole page in memory - the objects are 
instantiated. Do you have some kind of instance pool, so that object 
instantiation works faster?

- First of all, what do you do if an update occurs? Do you write to the disk 
immediately, or are the changes cached in memory as long as the page is 
written back to the disk as a whole?

- And secondly, how do you decide whether to keep the page in memory or 
release it to the disk?

- And thirdly, how do you guarantee atomicity and durability of a transaction? 
Do you have some kind of logging engine? Something else?

A load of questions, I know! Nevertheless, it might be interesting for 
everybody... ;)

I´m looking forward to your answers!

Thanks in advance,
Christian

> Hi,
>
> > > What is your isolation level?
> >
> > Not sure about non-repeatable and serailizable but definitely not
> > allowing dirty reads. Maybe Leo, Wieslaw or Falko could share some light
> > on this?
>
> Ozone allows only exclusive writing/update transactions. It means that
> all other read transactions must wait until the update transaction is
> finished.
> I think that this behaviour may be compared to RDMBS serializable
> transaction isolation level.
>
> Cheers,
> Wieslaw
>
>
>
>
> -------------------------------------------------------
> SF.Net email is sponsored by: Discover Easy Linux Migration Strategies
> from IBM. Find simple to follow Roadmaps, straightforward articles,
> informative Webcasts and more! Get everything you need to get up to
> speed, fast. http://ads.osdn.com/?ad_id=7477&alloc_id=16492&op=click
> _______________________________________________
> Ozone-users mailing list
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/ozone-users


-------------------------------------------------------
SF.Net email is sponsored by: Discover Easy Linux Migration Strategies
from IBM. Find simple to follow Roadmaps, straightforward articles,
informative Webcasts and more! Get everything you need to get up to
speed, fast. http://ads.osdn.com/?ad_idt77&alloc_id492&op=click