[omniORB] Authentication; Garbage Collection

[Duncan Grisby]

On Thursday 22 July, "Alex Suzuki \(ML\)" wrote:

> Hmm. I don't know if this will work in my case. Perhaps my design is flawed.
> I have Person objects that represent a single person (comprised of data in
> several DB rows), with attributes like
> 
>    attribute readonly DateType birthdate;
>    attribute string nameOfDog;
>    ...
> 
> and a method
> 
>    void commit();
> 
> which writes the person back to the database. Now I might have two clients,
> one with readonly access and one with write access, which both work on the
> same Person object. I cannot distinguish one call to commit() from a
> readonly client from a privileged commit() call.
> With your approach (if I understand correctly) I would have something like
> 
>   session.getPerson()
> 
> which would return a Person object that will perhaps through an exception
> if the commit() method is called (and the user is not privileged). However,
> it seems unnatural to me that there would be two Person objects (one for
> the privileged client, one for the non-privileged one) actually representing
> the same DB entity.

What you describe is a common pattern. The alternative is to use the
interceptor mechanism to pass around transaction tokens.

> > > 2) Garbage collection
> > 
> > Have you thought about using default servants? Most of my interfaces
> > that are thin wrappers around entities in a database end up becoming a
> > default servant. That way you have one servant for however many
> > references you create, and the servant just operates on a different
> > row depending on what ObjectID you give the reference.
> 
> I just looked up Default Servants in the spec. (again, I'm totally new to
> CORBA) and as I understood it, this works well for light-weight wrappers.
> However my person objects have a lot of state at the moment, since they
> basically internalize all the relevant DB data (which can be alot, because
> there is also a sort of "history" associated to the person which documents
> changes to various attributes) into their state. Maybe this is the wrong
> way to go?

You should get Henning and Vinoski's "Advanced CORBA Programming with
C++". I know you're not using C++, but the book contains lots of very
useful information about the kind of thing you are trying to do, as
well as details about the nightmares of the C++ mapping.

In the book, you'll read about something called the Evictor pattern,
which I think would be a good solution for you.

Going back to your original email, using reference counting for
garbage collection is very dangerous. You might trust your clients not
to maliciously hold on to references, but you can't protect against
crashes and network failures that cause a client to accidentally keep
a reference.

Cheers,

Duncan.

-- 
 -- Duncan Grisby         --
  -- duncan at grisby.org     --
   -- http://www.grisby.org --