Re: Re: Ozone List does not work anymore...?

Hi Per,

at first I´d like to wish you a nice vacation then!

For your information: I already worked with Ozone some time ago, so I have the 
practical experience. Nevertheless this time I need to know the concepts 
behind the product because they're are crucial in the context of my current 
project.

So I would appreciate your help and the help of others to clear the open 
issues. Naturally I won´t bother you any more in your vacations! But I would 
be very pleased if you could dive in the open issues when you´re back at 
home.

Perhaps the other core developers might help to clear the issues right now...?

Thanks in advance,
Christian

> Hi Christian,
>
> Actually this mail reached the mailing list a couple of days ago. Your
> summarizing points are basically correct.
>
> I'm on vacation so I will not dive into your open issues. However, best way
> to get started with Ozone is just to start! :) Use tests frequently for
> anything you are unsure of and you will develop empirical, first hand
> knowledge about how it works rather than relying on my weak memory ;)
>
> Best regards,
> Per
>
> Tuesday 05 July 2005 21.23 skrev Christian Merenda:
> > Hi Per,
> >
> > there are other people who can post to the list. I just gave it a try,
> > but it didn't work again. :(
> >
> > So I would be very pleased, if you could clear the points for me on a
> > personal basis. I need to know now, because I´d like to jumpstart with
> > Ozone, but there are several points I need to understand from the first
> > day on.
> >
> > In the following I send the e-mail I´m not able to post for a few days
> > now. I would appreciate the help of Leo and Wieslaw, too. Thanks a lot.
> >
> >
> > Hello Leo, Per and Wieslaw,
> >
> > I know, in my last mail I asked a lot of questions. Nevertheless, the
> > most of them were some kind of summary regarding my mailings with Per.
> > Thanks to you, Per! Wieslaw and Leo cleared the point about the isolation
> > level and transactional behaviour of Ozone. Thanks to you, too!
> >
> > Could you now write some short comments to the summary points. Are my
> > assumptions correct? And can you clear the open issues please.
> >
> > SUMMARY POINTS
> > ===============
> >
> > Summary Point 1:
> > 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.
> >
> > Summary Point 2:
> > 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.
> >
> > Summary Point 3:
> > 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. A writer may wait indefinitely, because of
> > upcoming read-only transactions.
> >
> >
> > OPEN ISSUES
> > ===========
> >
> > Open Issue 1:
> > What about timeouts?
> >
> > Open Issue 2:
> > 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.
> >
> > 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?
> >
> > How do you decide whether to keep the page in memory or release it to the
> > disk?
> >
> > How do you guarantee atomicity and durability of a transaction? Do you
> > have some kind of logging engine? Something else?
> >
> > Open Issue 3:
> > Do you have some kind of instance pool, so that object instantiation
> > works faster?
> >
> > Best regards,
> > Christian
> >
> > > I have no idea. Sometimes SourceForge is heavily loaded and it takes
> > > several days before messages goesw through. My guess is that this is
> > > what you are experiencing.
> > >
> > > Best regards,
> > > Per
> > >
> > > Monday 04 July 2005 11.06 skrev Christian Merenda:
> > > > Hello Per,
> > > >
> > > > I´ve tried several times now, but somehow I´m not able to post to the
> > > > ozone-list anymore. Do you have a glue about that? What is the
> > > > problem?
> > > >
> > > > Best regards,
> > > > Christian
>
> -------------------------------------------------------
> 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
> _______________________________________________
> 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