Roel De Nijs wrote:
First a general remark: you should only lock/unlock records when calling delete or update, not read.
Roel De Nijs wrote:1/ your Data class should be thread-safe, so it can be used in a multi-threaded environment (and your database file does not get corrupted). As a 2nd remark: you have to call lock-method before you make a call to update/delete method and finally you have to call unlock-method. An update/delete should only occur by the client that has successfully locked the record. Only 1 client at a time can lock a record, all other clients have to wait until the other client calls unlock, before trying to lock that record again.
Calls to lock/unlock should not be called inside the update/delete methods, but should be called seperately (in your business service).
Roel De Nijs wrote:2/ my find-method returns the same set of records. My GUI only shows exact matches. When I pass all null values to my find-methods, all records will be returned (but that's just my interpretation of the requirements). But returning all records is one of the must requirements if I'm not mistaken, so I'm curious to know how you implemented that one.
Roel De Nijs wrote:3/ because all my methods are synchronized, only 1 method can execute at a time. But of course an update of record 3, followed by a delete of record 5, create of a new record,... should occur without any problem, without corrupting your database file. You could use synchronized blocks, a class from the new concurrency API or simply mark every method as synchronized (the simplest approach possible)
I made create,read,update and delete with synchronized blocks. i have synchronized them to the randomAccessFile object.
Roel De Nijs wrote:1/ That's confusing me. You have to restart an application to see a booked entry What about refreshing the data doing a search? My gui is also not updated when another gui has made a change to the database file (e.g. a booking), but if this gui executes a new search, the booking will be visible
Roel De Nijs wrote:2/ It's not implicitly required to first end all operations before closing down the server, but you have to make sure your server is not shut down in the middle of a write operation (might result in a corrupted database file)
Roel De Nijs wrote:3/ I kept the logging I used during development in my code, but disabled all logging. I justified this decision in my choices.txt: these logging statements can be simply turned on and can be used by debugging the application when a bug is found or a new requirement is implemented
martin naughton wrote:I changed you build script a bit to work but now it is working. thanks a million. would you accept any enhancements on the script?