Marc Marechal

Hi,

Have you tested for concurrency problems in networking mode.
By example, when you perform a search on the GUI, you will use the DbAccess#find(), and then some DbAccess#read() to obtain the records corresponding to the record numbers found.
Do you ensure that, when you read the records, none have been updated by another network client since the time you found the record numbers corresponding to your search criterias. In case you have not checked that, it is possible that some records you read do not anymore correspond to your search criteria.

Marc
SCJP 5.0, SCBCD 5.0

Hi,

Mohamed,
In the specification document, in the methods of the Data interface, a parameter recNo is used.
But specifically in the Data#delete method :
// Deletes a record, making the record number and associated disk // storage available for reuse. // Throws SecurityException if the record is locked with a cookie // other than lockCookie. public void deleteRecord(long recNo, long lockCookie) throws RecordNotFoundException, SecurityException;
Until now I have used the index of the record in the database file as the record number, the recNo parameter.
Then, when I delete a record, I mark the record as deleted in the database file, and I respect the required behavior :
//making the record number and associated disk storage available for reuse.
But I would like to add a level of indirection : using a 'logical' record number associated with each 'physical' record number, aka the index of the record in the database file.
By using logical record indexes, when I delete a record, I use the logical record number as a key to find the physical record number. I mark the record as deleted in the database file, and I delete the mapping {logical record number, physical record number}.
All the logical record numbers I will use will be unique.
The logical record numbers will be the value given to the recNo parameters in the Data interface.
In this case, I wonder if the required behavior will be respected :
//making the record number and associated disk storage available for reuse. public void deleteRecord(long recNo, long lockCookie)
since I will never reuse the logical record number, the recNo parameter.
But I will make the physical record number, aka the index in the database file, of the deleted record available for reuse.

The real usefulness of this design is that I will update the logical record number when I will update a record.
The network clients having an old, invalid logical record number for a record will receive a RNFE if this network client try to update a record with this invalid logical record number.
Thus this will free me of updates crunch by multiple clients.

Since in the specification document it is stated :

Any methods that throw RecordNotFoundException should do so if a specified record does not exist or is marked as deleted in the database file

I suppose I am allowed to use RNFE for other purposes.

My asking is not if this will work or not, or how to do it, but your opinion : by not reusing the value of the recNo param associated with the record to delete in the
//making the record number and associated disk storage available for reuse. public void deleteRecord(long recNo, long lockCookie)
am I breaking the requirements in using such a design, and thus, does this will give me an automatic failure ?

I suppose I respect the requirements, since I make the deleted record and the physical record number available for reuse, but I am not sure of it.

Hi,

Mohamed,
I will save the logical record numbers in a map, the map itself being in a singleton class. I will not write the logical record numbers in any file.
But I just want an opinion wether or not my design should give me an automatic failure.

Thanks,
Marc
SCJP 5.0, SCBCD 5.0

Hi,

Thanks for your answers.

Kevin,
I think that when a record is marked as deleted, by its flag, it is available for reuse and will be overwritten when needed. So you can not think that it can be "undeleted" by changing its flag to available, since it could have been overriwritten in the meantime. And also it is your interpretation that name + location is a primary key for a record, but I have see it nowhere in the specification document.

Mohamed,
I intend not to alter the database format. The physical record numbers are the indexes of the records in the database file, and the logical record numbers will be stored in a map, in association with the physical record numbers. This map will be part of a Singleton class.

But my real question is :

In the Data interface, in the methods where the recNo parameter is used, I intend to use a logical record number in place of the physical record number. The logical record number will not be reused, but I will reuse the physical record number, in association with a new logical record number.

But in the specification document :
// Deletes a record, making the record number and associated disk // storage available for reuse. // Throws SecurityException if the record is locked with a cookie // other than lockCookie. public void deleteRecord(long recNo, long lockCookie) throws RecordNotFoundException, SecurityException;
So in this case, the recNo parameter is a logical record number which will not be reused, but I will reuse the physical record number, in association with a new logical record number.
But I wonder if this violate the "making the record number [...] available for reuse", and thus, does this will give me an automatic failure ?

Thanks,
Marc
SCJP 5.0, SCBCD 5.0

Hi all,

I am doing B&S.
My delete method is :

// Deletes a record, [b]making the record number and associated disk // storage available for reuse[/b]. // Throws SecurityException if the record is locked with a cookie // other than lockCookie. public void deleteRecord(long recNo, long lockCookie) throws RecordNotFoundException, SecurityException;

I use the physical record numbers as the indexes of the records in the database file.
I would like to use logical record numbers associated to the physical record numbers, and only use the logical record numbers in the DBAccess interface.
The logical record numbers will be unique, never reused, automatically generated.
So in this case, the recNo parameter is a logical record number which will not be reused, but I will reuse the physical record number, in association with a new logical record number.
But I wonder if this violate the "making the record number and associated disk storage available for reuse."

Thanks,
Marc

Hi,

I have seen in another post that IBM solution developer tests should be released in November, and advanced developer tests should be available in March.
Solution developer is already there, so I think all tests for ICED V6 should be there in March-April 2006.

http://forums.objectsbydesign.com/forumdisplay.php?s=c43f4c9d4e1226b7694232b31c153b40&forumid=5

Hello,

I have passed today SCJP 5.0 with (only) 65%.

My lowest scores were on API contents and Concurrency.
I should have done more small tests programs with Threads.

I made a 70% on Collection/Generics. For the generics, you need to study what is in the Gilad Bracha article on Sun website : "Generics in the Java Programming Language".

The time to answers the questions is enough, but it is difficult to concentrate 3 hours long.


Regards,
Marc.

Hi,

It is the same thing : turns ones to zeros, and add one.

Marc.

Hi,

I don't have the same error compiling with javac 1.5.0_03 :

C:\Temp\Family.java:22: incompatible types
found : java.lang.Object
required: java.lang.String
for(String name : offspring)


Also, you should change

public void display(LinkedList offspring) {

to

public void display(LinkedList<String> offspring) {

to avoid the preceding error.


Marc.

class A implements Runnable
{
public void run()
{
System.out.print(Thread.currentThread().getName());
}
}


class B implements Runnable
{
public void run()
{
new A().run();
new Thread(new A(),"T2").run();
new Thread(new A(),"T3").start();
}
}


class C
{
public static void main (String[] args)
{
new Thread(new B(),"T1").start();
}
}


/*

1. A new thread object is created, named "T1".
This thread run() method is B.run()
This thread object "T1" is started, AKA : a new thread of execution is created by the call to start() : we have now 2 threads running : the main thread and a new thread "T1".

2. Concurently, 2 things happen :
- The main thread has nothing more to do. It finish by leaving the main method.
- The new thread "T1" launch the run() method of class B.
In this run() method :
a) A new A object, subclass of Runnable, is created.
This A object launch its run() method. This will not create a new thread, since A.start() has not be called.
This will print the name of the current thread : "T1".
When A.run() is finished, the next instruction of B.run() is executed. We still are in the "T1" thread.
b) This next instruction create a new Thread object, based on Runnalbe A, named "T2". The run() method of this thread will then be A.run().
The A.run() method is launched. This will not create a new thread, since start() method of this new thread object is not called.
A.run() will print the name of the current thread, wich is still "T1".
As above, When A.run() is finished, the next instruction of B.run() is executed. We still be in the "T1" thread.
c) The next instruction create also a new thread object, based on the Runnable class A, named "T3".
The start() method of this thread object is launched, creating a new thread.
At this point, we have 2 threads running, "T1" and "T3" :
Concurently :
- "T1" will finish executing B.run() ;
- "T3" will begin executing A.run(), since "T3" is created from Runnable A.
"T1" will end and leave B.run(), then end and leave C.main(). And then "T1" thread is finished.
"T3" will execute A.run(), print the name of the current thread : "T3", and then end.
*/

See in effective java programming Language Guide, item 8, to see a good way to make a hashCode().

'A good hash function tends to produce unequal hash codes for unequal objects. Ideally, a hash function should distribute any reasonable collection of unequal instances uniformly across all possible hash values.'

A rule is given.
In short, in your case, it will be :

public int hashCode()
{
result = 17;
result = result * 37 + getI1();
result = result * 37 + getI2();
return result;
}


So the answer E will best distribute unequals Test objects.

HashCode is a function used in hash tables.

You can see this for a good example and explanation : http://www.sparknotes.com/cs/searching/hashtables/section1.html

In Java, hash tables are used for HashSet, HashMap, ...

The hashCode() function need to be defined in objects you want to store in a collection implementing a hash table, such as HashSet, ...

For a good way to implement hashCode(), you should look at Effective java Programming Language Guide, Item 8.

For a tutorial on Collections in Java, you can look at : http://java.sun.com/docs/books/tutorial/collections/index.html

See Tutorial on assertions at : http://java.sun.com/j2se/1.4.2/docs/guide/lang/assert.html

See the SUN tutorial : Programming With Assertions :
http://java.sun.com/j2se/1.4.2/docs/guide/lang/assert.html

And Effective Java Programming Language Guide, rule 23.

Programming With Assertions


Do not use assertions for argument checking in public methods.

Argument checking is typically part of the published specifications (or contract) of a method, and these specifications must be obeyed whether assertions are enabled or disabled. Another problem with using assertions for argument checking is that erroneous arguments should result in an appropriate runtime exception (such as IllegalArgumentException, IndexOutOfBoundsException, or NullPointerException). An assertion failure will not throw an appropriate exception.


Do not use assertions to do any work that your application requires for correct operation.

Because assertions may be disabled, programs must not assume that the boolean expression contained in an assertion will be evaluated.

Effective Java Programming Language Guide, rule 23


For an unexported method, you as the package author control the circumstances under which the method is called, so you can and should ensure that only valid parameter values are ever passed in. Therefore nonpublic methods should generally check their parameters using assertions rather than normal checks. If you are using a release of the platform that supports assertions (1.4 or later), you should use the assert construct; otherwise you should use a makeshift assertion mechanism.