Thomas Mathai

Greenhorn
+ Follow
since Apr 01, 2001
Merit badge: grant badges
For More
Cows and Likes
Cows
Total received
0
In last 30 days
0
Total given
0
Likes
Total received
0
Received in last 30 days
0
Total given
0
Given in last 30 days
0
Forums and Threads
Scavenger Hunt
expand Ranch Hand Scavenger Hunt
expand Greenhorn Scavenger Hunt

Recent posts by Thomas Mathai

Originally posted by Marco Poehler:
I think you can use the constructor:
String( bytes[] ascii, int offset, int length )
which uses the platforms default character encoding.
right ?
marco



IMHO, you do not really want to leave it to the platform's default encoding. Your binary file db.db uses only 1 byte per character. So you would want to enforce ISO-8859-1 encoding.
the way suncertify.db.Data is provided to us it opens file in "rw" mode so it automatically uses the db file exclusively, you don't need to worry about that.
However, if you leave it as is, an attempt by another thread to open the db will result in exception

Gennady:
Let me clarify what I said.
Let us assume there is one instance of Data associated with db.db. If you now create a second instance of Data (associated with db.db just like the first instance), we will then have two
instances both reading/writing db.db. This will create problems since there is no synchronization across them.
I do not think that an attempt to create a second instance will throw an exception as you appear to suggest. Correct me if I am wrong.
With a Singleton, you prevent the creation of a second instance of Data in the same JVM (but it will not prevent additional instantiations of Data from other JVMs).
Actually we WILL want to permit other instances of Data as long as each instance is reading/writing separate binary database files. Because each binary file is like a separate table in the
database. (There is only 1 table for this developer assignment.)
So what we really want to do is to ensure that at most one Data object is reading/writing db.db i.e. what we really want is a file lock.

[This message has been edited by Thomas Mathai (edited October 23, 2001).]
[This message has been edited by Thomas Mathai (edited October 23, 2001).]
If you search this forum, you will find Peter repeatedly warning
against the use of Singleton in connection with db.db.
What you really need here is a file lock to ensure that db.db is associated with at most one instance of Data. Singleton will not do this!
In fact, as Peter has pointed out, a Singleton Data will prevent you from extending your database to include additional tables in the future.
Hope this helps
Farouk:
You raise an interesting issue. It struck me too and I assumed that it is a typo and that the comments should actually say
For this assignment, the key field is the flight number field.
I see that writeRecord() is private. So as Narayan pointed out, it can only be called through some of the public methods like add, modify which are synchronized. So writeRecord() need NOT be synchronized. The same argument will apply to readRecord(). But I see that readRecord() is synchronized! I don't see why it should be synchronized either.
The issue that Matt brought up also means that if you are synchronizing on Vector or some such common object, you will need to call notifyAll instead of notify. If you call notify, you will only wake up one thread and this thread may be waiting on another record!
I am trying to debug a GUI application with FORTE, without much success so far. It somehow can't find all the classes or so it says. Have people have had good luck with FORTE on WIN 98?
Thanks Vladimir. But so is the readRecord method. It is private too, but it is synchronized. Isn't this inconsistent, if nothing else, from a style viewpoint?
Can anyone explain why the writeRecord method is NOT synchronized while all the other methods are?