Re: [Ganymede Help] Access the field.........

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

| On Tue, May 07, 2002 at 03:34:41PM -0400, gauravb2@excite.com wrote:
| 
| Jon,
| 
|  My basic object here is to increment the serial number of a domain if
| a record in that domain is changed. Now what i was doing previously(
| which obviously didnt work) was i was trying to change the serial
| number in a domain when ever a transaction was committed in a record
| that exists in that domain ...but then i cant change a field in server
| during the commit phase, hence now i wrote a builder task file in
| which it checks on transaction commit whether a particualr base has
| changed. If a base has changed it traverse through all the objects in
| that base and checks to see what is the object that has been
| modified....depending upon the object thats has been modified it
| should increment the serial number of the domain in which it
| exists.

The problem is that doing this causes concurrency issues.  If every
time your DNS build runs it may try to bump the serial number object
in the transactional store, it has to edit the serial number object
and commit a transaction, which will immediately trigger another build
task as soon as the first completes.  This implies that you'll
_always_ get back-to-back builds, even if the second one can examine
the bases using baseChanged() to avoid scanning the objects looking
for individual changed objects.  If your builder task isn't really
smart, you'll wind up having the server constantly running your
builder task, back-to-back-to-back in a vain attempt to get to a state
where no objects have been changed.

I still very much maintain that the design best in keeping with the
Ganymede architecture is to worry about the serial numbers in the
external build scripts.  Let them worry about build-time issues, and
let the Ganymede transactional database worry about user data.

If you want to ignore my advice, that's fine, but I can't guarantee
that what you think you want to do will work.  All I can do is tell
you what actually _will_ work.  If you don't like that, it'll be up to
you to rewrite the Ganymede server so that it fits with the way you
think the Ganymede infrastructure should function.

| Now here when ever i try to modify a field i get the same
| error.....that i dont have permission to change the field. Is this
| because of the same reason that i cannot change any field while in
| commit phase

No, not exactly.  First of all, you can't just make changes to an
object that you get from the enumerateObjects() method.

Remember, there are two kinds of database objects in
Ganymede.. DBObjects are read-only objects that you can access using
viewDBObject() or, in the case of a GanymedeBuilderTask, by pulling
DBObject references from the enumerateObjects() enumeration.

DBObjects are always read-only.  You can't ever change their fields.

If you want to edit an object, you need to pull the Invid from the
read-only object using object.getInvid(), then you need to call
GanymedeSession.edit_db_object() on that Invid to check out an
editable copy of the object (a DBEditObject).  And the
edit_db_object() method can fail if your session doesn't have
permission to edit the object, or if another session has that object
checked out for editing at that moment.  Changes made to DBEditObjects
aren't finalized until you call commitTransaction() on the session to
lock in the changes.

Okay, that's the first problem, and the reason you're seeing the
errors you're seeing.  The second problem is that the
GanymedeBuilderTask class is simply not designed to make changes to
the Ganymede transactional store, at all.

Before it runs builderPhase1(), the GanymedeBuilderTask base class
automatically obtains a dump lock on the entire Ganymede database.
This dump lock ensures that no transactions will be committed during
the time that the builderPhase1() method is scanning the database for
data to be written out to external data files.  If you try to force
builderPhase1() to do openTransaction(), edit_db_object() calls, and
commitTransaction(), it will work, but as soon as commitTransaction()
is called, your builderPhase1() method will lose the dump lock, and
any other user or session will be free to start making changes to the
database.  If you haven't finished scanning the database, you'll be at
risk of having the data you write out be transactionally inconsistent,
with some data scanned from before a user's transaction and some data
scanned from after, which may be entirely wrong.

Using a GanymedeBuilderTask subclass to apply edits to the database is
inherently risky.  What happens if your builder task doesn't get run
until such time as someone has manually checked out your domain object
for editing?  If that happens, your builder task won't be able to
check out the domain object for editing, since only one session can
edit an object in Ganymede at the same time.  What do you do then?  Do
you just decide to forget about the build because you can't bump the
serial number in the transactional store?  What do you do?

| As far as oldLastRunTIme is concerned i got the value
| when i changed the option from "run periodically " to "run on
| transaction commit"(now if i cant change the field in an object
| because of the reson that this option is being checked and if i
| uncheck this option and check the run periodically option then i wont
| get the value of OldLastRunTime.....) .......Now i am confused as to

The problem with not being able to change the field is all about your
not using edit_db_object(), it has nothing to do with 'Run Periodically'
vs. 'Run On Transaction Commit'.

| how do i increment the value of the serial number as nothing seems to
| work. neither the plug in code....nor the task.Pls let me know how to
| approach this........I am attaching the java code too please have a
| look at it.

Approach it by doing it outside the Ganymede transactional data store,
as I said last time.

| Thanks Gaurav

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

----------------------------------------------------------------------------
To make changes to your subscription to the Ganymede Help list, send
mail to majordomo@arlut.utexas.edu.

To unsubcribe, include the line

unsubscribe ganymede-help

in the body of your mail message

Visit the Ganymede web page at http://www.arlut.utexas.edu/gash2

----------------------------------------------------------------------------