Mailing-List: contact ojb-dev-help@db.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "OJB Developers List" <ojb-dev@db.apache.org>
User-Agent: Microsoft-Entourage/11.0.0.040405
Date: Wed, 23 Jun 2004 09:56:08 -0400
Subject: Thoughts on Locking issues
From: "Robert S. Sfeir" <robert@codepuccino.com>
To: OJB Developers List <ojb-dev@db.apache.org>
Message-ID: <BCFF0438.2C88%robert@codepuccino.com>
Mime-version: 1.0
Content-type: text/plain;
	charset="US-ASCII"
Content-transfer-encoding: 7bit

Hey guys,

Real quick before I disappear for the day...

I was discussing some ideas about hot to handle optimistic locking in post
1.0 with Brian, and here are my thoughts on a couple of possible solutions.

First idea:

To handle locking correctly across all DBs we have to rely on our own
mechanism, and I think that the best way to do this would be to have our own
table which stores the object id and its serial id in that table.

On object select, you'd update that table with the ids of the returned
objects.  Now I know this can be a lot of overhead, so my suggestion is to
perhaps have something like a servlet running which can batch process the
ids after the select is done and data is returned to the user.  Something
that would happen in the background.  Chances are the user will not be fast
enough to update the objects to be affected by the small delay in updating
the ojb lock table.  This servlet could also be multithreaded but I don't
think it's necessary.

Second thought to this idea is that instead of just locking objects on
select, we can provide a method which does a special select, a
getObjectsForEdit(), where when this method is called, that's the time that
you update objects to the lock table.  This way when you do a 'normal'
select, you get the objects and nothing gets marked for lock, and we
minimize the overhead.

In either case, there should also be an option for automatic deprecation of
locks.  This should be something set by the user.  Say a user selects a
bunch of objects, if another user comes along and selects the objects and
updates them, we check with the table, if the last time these objects are >
then the pre determined timestamp, we override the lock, and allow the
update.  If it's less we give the engineer a choice to figure out what to
do.  These choices I think would be:
    1- Throw an error and tell the user object is already locked for edit
    2- Give them a method to try a gain without having to write too much
code, something like tryPersistAgain(numTimesToTry) so we can write a while
loop which would try to persist it the specified number of times, then fail
again.
    3- ignore lock completely and update, in which case we update our lock
table so the next user has the same choices.


Second idea, which I don't think is as reliable to code:

Do same as first but without tables, store objectid and serialid in a
Hashtable as objects get selected.  This will probably too memory intensive,
however we could have a process which removes objectids from the Hashtable
after a certain period of time so we can keep memory to a minimum.  I have
code which I used for cached table data in one of my apps which does this.
In my case it works great, but I don't know how much we can rely on it for
this purpose.  Here is my code for it:

(In either case we can use this code to either persist the objects in the
Hashtable to the DB or just keep it there, code needs slight mod to retrofit
into the suggestion above.)

  /**
   * Stores data that was selected from the database into id/name pairs in a
Hashtable for later fast retrievals. This
   * is meant to get single values quickly.  If you need lists you need to
look at RexListFunctions. Generally use this
   * method when you need to display just the result of a name based on an
ID.  For example if you have a userID
   * displayed in a form, instead of the ID look up the name of the user
based on the ID in the hashtable
   *
   * @param category
   * @param name
   * @param id
   */
  public static void cacheNameAndID( final String category, final String
name, final int id )
  {
    Hashtable map = _getCategoryMap( category + ".nameByID" );
    map.put( new Integer( id ), name );
    map = _getCategoryMap( category + ".idByName" );
    map.put( name, new Integer( id ) );
  }

  private static Hashtable _getCategoryMap( final String category )
  {
    Hashtable map = ( Hashtable ) categoryMap.get( category );
    if( map == null )
    {
      map = ( Hashtable ) categoryMap.get( category );
      if( map == null )
      {
        map = new Hashtable();
        categoryMap.put( category, map );
      }
    }
    return map;
  }

  /**
   * Gets the Name of a value in a category from a hashtable using the ID.
   *
   * @param category the hashtable name.  .nameByID will be appended to
this.
   * @param id       the ID of the name you're looking for.
   *
   * @return the value of the ID; the name.
   */
  public static String getNameByID( final String category, final int id )
  {
    final Hashtable map = _getCategoryMap( category + ".nameByID" );
    if( map.get( new Integer( id ) ) == null )
    {
      return "";
    }
    else
    {
      return ( String ) map.get( new Integer( id ) );
    }
  }

  /**
   * Gets the ID of a name in a category from a hashtable based on a name.
   *
   * @param category the hashtable name.  .idByName will be appended to
this.
   * @param name     the name who's ID you're looking for
   *
   * @return the value of the name; the ID.
   */
  public static int getIDByName( final String category, final String name )
  {
    final Hashtable map = _getCategoryMap( category + ".idByName" );
    return ( ( Integer ) map.get( name ) ).intValue();
  }


---------------------------------------------------------------------
To unsubscribe, e-mail: ojb-dev-unsubscribe@db.apache.org
For additional commands, e-mail: ojb-dev-help@db.apache.org