NX: Instantiating the data access class

[Mogens Nidding]

Hi guys (and gals).
This is the design I am planning to implement: There are a couple of
statements I am unsure of (not telling you which ones ), so any comments are welcome.

I need many at least one Data instance per client because the lock(int recNo) method in Data must be able to identify the calling client to guarantee that that one client and no other clients can access the locked record.

A particular Data instance is a great identification of a client.

You could even say that a Data instance IS a client. I can't see a better way to identify the client.

Using the current thread as client identification won't work because RMI makes no guarantees as to what thread will invoke the exported methods.

All data instances (for a given canonical database path name) must access the same shared file and the same shared list of locks.

I COULD make the shared file and shared list of locks static because I KNOW there is only one file, but it would be more elegant not to restrict the program to one file. (Or perhaps it would just be more work than is called for?)

This means I must maintain a mapping from canonical path name to a shared file. Having the mapping be a static variable of Data is fine.

[Mogens Nidding]

My assumptions above had some interesting consequences. They led me to create an inner class, Table, to encapsulate all those objects that were shared by all the Data instances:

public class Data implements DBMain {
    // Lots of other stuff
    /**
     * Simply groups objects relating to a file-level database table:
     * An open database file, cached header data, and record locks. 
     * Since only one table is expected, all Data instances are expected, 
     * not required, to share the same Table instance.
     */
    private static class Table {
        /** The open database file. */
        private RandomAccessFile file;
        private Map locks;
        private Header header;
    }
    /** Initializes header from DB file. Called during initialization. */
    private final void readHeader() throws IOException {
        table.header = new Header();
        table.file.seek(0);
        table.header.magicCookie = table.file.readInt();
        // and so on
    }
    // All public methods can then synchronize on the table:
    public void lock(int recNo) throws RecordNotFoundException {
        Object client = this;
        synchronized (table) {
            // Free to tamper with table.locks and table.file in here.
            // Can register client as lock holder for record recNo.
        }
    }
}

I personally think the dotted table.header.magicCookie notation makes the data organization very clear. However, I am beginning to doubt my coding style, since it does smell a bit like C structs.
My inner Object Oriented Design leprechaun is shouting to me that I should obviously move all the table accessing methods into Table class. Trouble is that "the table accessing methods" just so happens to be the bulk of the Data class. In effect, the Data class will just become a thin adapter that doesn't really do anything except identify clients to the Table lock/unlock methods class, as in

public class Data {
    public void lock(int RecNo) {
        Object client = this;
        table.lock(recNo, client);
    }
}

Is it OK to just have the Data class be a thin adapter? Anyone has any advice? Am I even asking a real question?
Bewildered regards,
Nicky
[ March 12, 2004: Message edited by: Nicky Bodentien ]

[Javini Javono]

Hi,

Is it OK to just have the Data class be a thin adapter?

Concerning your coding example, where the Data class delegates
it's work to a LockManager class, that's fine, I would suspect.
In general, my code operates the same way.
Aside: Note this interesting remark from George in a relatively recent
post: where he said that both in local and remote mode, he used
his LockManager, and he received a 100% score.
Concerning the organizing of the files to get the "One-ness pattern"
(a name I'm making up). That is, you have one database file,
and associated with it, are single instances. And, if you had another,
second database file, associated with it would another set of
single instances.
Right now, as I work with JUnit for unit testing, and continue to augment
the higher system testing of my database using George's super software
exerciser as the thread generator, I've taken the shortest path, to get things
moving: i.e., used singletons, used static, et cetera.
Now, once I'm comfortable that my design is flawless, then I've decided that
the best route to take to create this "one-ness pattern" is to use the
factory pattern, although, when you create a set of components, the factory
pattern may have a different name, such as, and I make this up: meta
factory pattern (such as a pattern which creates one look and feel which
consists of different components).
I am not a Java style expert, but, it would be my opinion that you don't need
this kind of construct: ClassA.ClassB.ClassC.element, instead, at least this
is how I do it, if ClassA contains a ClassB instance, ClassA simply has a reference
to ClassB. It is not unusual, at least for how some of classes are set up for
other functions, to have ClassA contain a reference to ClassB which in turn contains
a reference to ClassC which in turn contains a reference to ClassD.
But, this may be a manner of style. For instance, if only ClassA refers to its own
instance of ClassB, maybe ClassA.ClassB is more appropriate. So, at least you
have me thinking about this; but, since you declare the inner class as default
access, private, or what have you, you can still do the same thing with standard
references.
In general terms, I prefer stand-alone classes. I like a relatively small source
.java file. I find it easier to work with. Granted, however, you will find instances
in text books, for instance, if you were writing an Iterator for your own collection
class, where having inner classes makes sense.
Forgive me for perhaps rambling, I'm sure others will have more precise comments
on your question, and I look forward to reading their responses.
Thanks,
Javini Javono

[Javini Javono]

Hi,

Is it OK to just have the Data class be a thin adapter?

Concerning your coding example, where the Data class delegates
it's work to a LockManager class, that's fine, I would suspect.
In general, my code operates the same way.
When I answered this question last time, I was basing my response
on my memory. Although there may be no tangible difference, and keep in
mind that certainly things will change if and when I decide to
refactor, here are my classes:

//Your example.
public class Data {
    public void lock(int RecNo) {
        Object client = this;
        table.lock(recNo, client);
    }
}
//My corresponding method.
public class Data implements ... {
    public void unlock(int recNo) throws RecordNotFoundException {
        abstractD.unlock(recNo);
    }
}
//where abstractD extends Object.
//This class extends abstractD having this method:
    public void unlock(int recNo) throws RecordNotFoundException {
        LockManager.unlock(recNo, clientId);
    }

I'm not suggesting that you should consider the above good style or even
emulate it; but it simply shows that I treat Data very thinly indeed (at least
for now, unless I change things around in the future and refactor). The
net effect, as you can see, however, is almost identical (I don't yet pass
in "this", this might change, but if, when, or how, is not yet known yet)).
Thanks,
Javini Javono
[ March 14, 2004: Message edited by: Javini Javono ]

[Mogens Nidding]

Thanks for your replies. Funny that we have almost the same design :-)
I still haven't figured out a totally clear design. My latest approach is a hybrid where the Data class handles all the locking and a TableFile class handles all the I/O:

public class Data implements DBMain, Client {
    private static class Table {
        private TableFile io;
        /** Maps record number (Integer) to lock holder (Client). */
        private Map locks;
        private Table(File dbPath) throws IOException {
            io = new TableFile(dbPath);
            Map locks = new HashMap();
        }
    }
    /** Serves as synchronization lock object. */
    private Table table;
    public void update(int recNo, String[] data)
            throws RecordNotFoundException {
        synchronized (table) {
            waitForAccess(recNo);          // checks table.locks
            table.io.update(recNo, data);
        }
    }

I good things about the new design are that

the locking related code

now has the client id it needs at hand in form of the this
reference, and

the seperate locking and I/O reponsibilities are now

also handled by seperate classes!

The downsides are that

not only is my inner Table class back - now I also

need to synchronize explicitly on the table object.

with every new helper class, I feel an obligation to

generalize its API and documentation beyond just helping
with the one thing it was intended to do: For instance,
can I excuse that TableFile.update throws the odd
RecordNotFoundIOException instead of a proper IOException?
Because if I can't, then the helper class soon becomes
more burdensome than helpful.

In the end though, I think I'll stick with the later
design.