Re: [Ganymede Help] Re: error....

[Jonathan Abbey <jonabbey@arlut.utexas.edu>]

| Hi Jon,
| Let me try to explain the problem i am facing. I have two different 
| objects defined in the schema called "Domain" and "Address". These two 
| objects are controlled by their respective java classes. Now what i am 
| trying to do is whenever i change a field in the address object and 
| commit the transaction, i want to increase the index vale in the 
| field "Serial Number" which is in "start of authority" object by a 
| value of 1. Every time i get an error saying 
| 
| Ganymede.createErrorDialog(): dialog says don't have permission to 
| change field / non-editable object for field Serial Number in object 
| villanova.edu
| 
| I am attatching the code with the mail .....the concerned code is 
| written in public void commitphase2(). I am using setValueLocal() 
| method to reset the value of the field. Please look at it. Thanks for 
| your help.

The problem is that you are trying to modify data fields during
transaction commit.  This is not allowed.

Once a transaction begins to commit, it calls commitPhase1() on all
the objects that have been touched during the transaction.  Each
object's commitPhase1() method is supposed to return an error if the
object is not ready to be checked in.  Once all objects have reported
success in their commitPhase1() methods, the transaction commit logic
then loops over all the objects in the transaction and calls
commitPhase2() on them.

If Ganymede allowed changes to be made to the objects after their
commitPhase1() methods were called, the system couldn't guarantee that
the objects were in a consistent state for the transactional commit,
so the commitPhase1() logic causes all subsequent data manipulation
operations in the object to be blocked.

The Javadoc for the commitPhase2() method in the DBEditObject class
clearly documents this, as it says:

 * <p>This method should NEVER try to edit or change any DBEditObject
 * in the server.. at this point in the game, the server has fixed the
 * transaction working set and is depending on commitPhase2() not trying
 * to make changes internal to the server.</p>

You need to think about what you are trying to achieve here.  If you
want to make sure that the serial number for the zone gets updated any
time that the zone is rebuilt, then you should have the serial number
be maintained by the external build logic, rather than the internal
transactional database logic.

At ARL, we don't keep the DNS zone serial number in Ganymede itself,
but rather have an external script that is responsible for tracking
the serial numbers for each zone, and which increments the serial
number as part of the DNS build process, which is conveniently
serialized (i.e., only one DNS build can be run at a time) by the
Ganymede build scheduler.

I'd really recommend you rethink your schema design a little bit and
try to do the same.

If for some reason you absolutely, positively, _have_ to keep the
serial number for the zone in a database object, you will need set
things up so that as soon as any DBObject whose modification would
cause the zone to need to be updated is changed, the serial number in
your domain object would have to be incremented, which would
necessitate an exclusive lock on the domain object, which would
prevent more than one person at a time from ever being able to edit
anything having to do with the domain at the same time.

| Gaurav Bhargava

-------------------------------------------------------------------------------
Jonathan Abbey 				              jonabbey@arlut.utexas.edu
Applied Research Laboratories                 The University of Texas at Austin
Ganymede, a GPL'ed metadirectory for UNIX     http://www.arlut.utexas.edu/gash2