[omniORB] Authentication; Garbage Collection

Alex Suzuki (ML) ml at cynox.ch
Thu Jul 22 13:14:15 BST 2004


Hi,

First of all thanks for your reply.

On Thu, 22 Jul 2004 03:25:30 -0700, IxokaI <ixokai at gmail.com> wrote :
>    Basically, the Authenticator interface returns a Session reference,
> through which the user  gets everything they need.
>     If they wish to access a resource, they call resouceManager =
> session.getResourceManager(). The Session's servant creates (or
> reuses) a resource manager reference, passing itself in as an argument
> to the servant, and returns it.

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. In my current implementation I use a timestamp attribute
in the Person object to notify the user if a modification has been made
by someone else (concurrently). This would no longer work (or I would have
to move that into the DB).

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

Regards,
  Alex

BTW: You have a gmail account, lucky bastard! :)



More information about the omniORB-list mailing list