Win a copy of Five Lines of Code this week in the OO, Patterns, UML and Refactoring forum!

Rajesh Moorthy

Ranch Hand
+ Follow
since Sep 23, 2008
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 Rajesh Moorthy

Thanks Andrew & Roberto for your suggestions.

My pseudocode for updateRecord looks the following now:



Do you feel this is the right way to proceed?

Thanks & Regards,
Rajesh.
Hi,

This cookie (the long value) is used just to identify the client that locked the record that is about to be updated/deleted. When you lock a record, you have to somehow associate its number with this cookie (you can use a Map<Long, Long>, for instance, where the record number is the key, and the cookie is the value). In your update/delete methods, you just verify if the cookie that is being used to update/delete a particular record is the same one that you returned to the user when that record was locked. You're in the right path, you just have to add this verification to your update/delete methods and you're fine!



Please refer the statement in bold above.

Accordingly I do the following for update/delete record:

1) Lock Record and obtain the cookie
2) Pass the Cookie to update/delete method.
3) Here in the update/delete method, I do not already have a value to compare it against the cookie. How should the comparison be done?
4) Unlock record.

Thanks & regards,
Rajesh.


Thanks Roel, for your quick reply.

I will try the approach, any way !

Regards,
Rajesh.

Rajesh,

Do you mean in your program? I implemented the find (the method from sun's interface) in my Data-class and i implemented find2 (the method from my own interface). find2 uses a call to find because it uses the same logic to find the record numbers.

In the program i use a call to find2 (and find is never called).

Regards,
Roel



Sorry for the late reply, as I could not work on the topic for a few days.

As Roel said, let us assume:
find -> the method from sun's interface
find2 -> the method from my own interface

"find" returns the record numbers. As I do not want the record numbers, I write "find2" to directly return the records.

Therefore, "find" will not be called from anywhere, not even from "find2". In other words, the method from sun's interface will be implemented, but will never be called from anywhere in the application.

Is this an allowed approach?

Thanks & regards,
Rajesh.
Hi Johnny...Do you plan to use the method from Sun's interface?
Hi Roel...Do you think it is necessary to use the method from Sun's interface?

When server received request for a search do two things on server
1. Find the record numbers (Using the find method) which match the search criteria
2. Staying on the server put records corresponding to the record numbers found at step 1 into a string array
THEN return the array to client instead of first sending record numbers to client and then again asking for records corresponding to those recNumbers.



If I use the method signature from Sun's interface, I should use the above algorithm.

Here's my thinking:
1) I will implement the functionality of the findByCriteria() method as expected by Sun.
2) However, I will not use this method.
3) I will write a separate method that is similar to the implementation of findByCriteria() method, but returns the matching records directly (not the record numbers).
4) This way, I can avoid reading the database for a second time, inorder to get the records matching the record numbers.

Is this an accepted approach?

When server received request for a search do two things on server
1. Find the record numbers (Using the find method) which match the search criteria
2. Staying on the server put records corresponding to the record numbers found at step 1 into a string array
THEN return the array to client instead of first sending record numbers to client and then again asking for records corresponding to those recNumbers.



If I use the method signature from Sun's interface, I should use the above algorithm.

Here's my thinking:
1) I will implement the functionality of the findByCriteria() method as expected by Sun.
2) However, I will not use this method.
3) I will write a separate method that is similar to the implementation of findByCriteria() method, but returns the matching records directly (not the record numbers).
4) This way, I can avoid reading the database for a second time, inorder to get the records matching the record numbers.

Is this an accepted approach?

Thanks,
Rajesh.



Hi Alain,

That is a very good explanation. Thank you very much.

Regards,
Rajesh.
Hello Dudes,

Thanks for your suggestions !!!

Regards,
Rajesh.
Thanks for your reply, Roel.

I am thinking of implementing the 3rd choice.

create an extra method in your own interface (that extends sun's interface) that will return the records instead of the record numbers



However, by the time the GUI displays the records from above, if the actual data file changes due to some other client activity, how do we handle it?

I did not understand the second choice, though. Could you please explain?

make an atomic operation of the find and multiple reads



Thanks again,
Rajesh.
Hello folks,

The findByCriteria() method in the data class returns an array of record numbers. The GUI receives these record numbers and searches the database (or cache) again for the actual records to be displayed.

Before the GUI reads the database, if another client changes the record, how will we make sure of the data integrity?

Thanks & regards,
Rajesh.
Thanks for your responses.

Here's my analysis:

1) We have to read 2 bytes only. This is the requirement. Therefore, we can read only "short" and not "int".

Hence, the following code may not fetch the intented result:
final int eof = database.read(flagBuffer, 0, FLAG_SIZE);

Please correct me if I am wrong.

2) The method writeShort() in RandomAccessFile accepts "int" argument and not "short" argument. This is the reason why writeShort(0x8000) works, eventhough the value is greater than the range of "short".


1) range of short is between -32768 to 32767
2) delete flag = 0x8000 = 32768. This is outside the range of short.



While reading the value, using readShort() will result in -0x8000 (-32768). For getting 0x8000 (32768), we should use readUnsignedShort().

----

Keeping the above points in mind, following 2 options can be chosen:

1)

if (readShort()==0) {
valid record;
}
else {
deleted record;
}

2)

if (readShort()==0) {
valid record;
}
else if (readUnsignedShort == 0x8000) {
deleted record;
}
else {
no idea; // can someone explain ?
}

If we choose Option 1 above, we can read/write "0" for a valid record and any other value for a deleted record. Then, what is the significance for the value 0x8000 ?

Am a little bit confused

Thanks & regards,
Rajesh.
Hey dudes, could anyone please provide inputs for the above question?

Thanks,
Rajesh.
By using RandomAccessFile.readShort(), the valid flag is being displayed as "0". However, it is not possible to use this method for the delete flag because:
1) range of short is between -32768 to 32767
2) delete flag = 0x8000 = 32768. This is outside the range of short.

What are the other ways to handle this scenario?

Thanks,
Rajesh.

The valid record flag 00 means empty bytes (nothing written on it) OR I should write 00 on it, and ofcourse I will be writing 0x8000 if I have to mark a record as deleted.



1) While reading the unedited database file, we should treat a record as valid if the flag contains empty bytes.
2) While writing a valid record, we should prefix 00 to the record.
3) This means, while reading an edited database file, we should treat both empty bytes and 00 as flags for valid records.
4) In this case, why should we prefix 00 for a valid record. In all cases, why shouldn't we treat the empty bytes for valid records?

In other words, why should we use the concept of 00 itself, when the original database uses empy bytes as the valid record flag?

Thanks,
Rajesh.
That clarifies.....Thanks a lot, Dudes !!!