Dennis Leong

great, thanks Roel.

Interesting!, i never thought about these possibilities for deadlock, but tested them out on my app and it's certainly a problem (for malicious coded clients only).

Roel - out of interest, how do you know when to throw an IllegalStateException ? is it done in your service layer method ?, as i cannot see how you could uniquely identify the client with the Data class lock() method.

Thinking about it, you could accept a unique client JVM identifier to your book method, then as part of your book method that uses lock(), you could concatenate it to the generated cookie, storing these values on your server. You could then enforce clients to only hold one lock at a time, or just return the same record number cookie. That is also introducing another layer of abstraction above your Data lock() method, as you cannot add this unique identifier as a lock() parameter, it must be implemented as is (just the record number). And since (presumably) the automated testing program would only test your Data class directly, without considering your service layer methods, then it's probably not something your going to be able to cater for, unless anyone's got any other ideas??

i tend to agree that it's over complicating things and beyond scope, and i haven't read of anyone else going to these lengths to prevent such deadlocks.

Hi Marcelo,

I had exactly the same problem, turns out to be a known issue with linux installations setting the 127.0.1.1 in /etc/hosts. If you remove that line;

127.0.1.1 lobo-laptop

you will probably find it works. Not too familiar with why this is set in a clean ubuntu install, but have made note of it in my javadoc and choices.txt.

you shouldn't need that setProperty either.

hiya all,
getting off-topic, but how many lines do you think the MainWindow should be before you may lose marks?
reason i ask is mines about 1000 lines (including comments), mainly due to the fact my JTable is feature rich with a CellRenderer, custom traversal policy, key/mouse listeners, and all sorts of bells and whistles. I would have much preferred to have subclassed JTable, but the consensus on here was that's not a good idea as it goes against the instructions. Yet having a large View class is not as maintainable. i mentioned all this in choices.txt.
cheers,

Hi all,

I've got a few questions about how to implement the update and delete methods that make use of a lockCookie to verify against your locked map.
In the Facade pattern, as given in the Monkhouse book, every method just passes the call straight through to it's relevant method in the DvdFileAccess or ReservationsManager class. And this works fine as it does not make use of lockCookies, and the general sequence for using update/delete from your middle layer is;

lock() update/delete unlock()

so when update/delete is called, your guaranteed to have the lock of that record (hence the boolean return of Monkhouse lock() method).

With the addition of lockCookie, as far as i can tell, it would make no difference. That is, with a lock(), update/delete and unlock() you should still have the lock of that record in order to update it. Now since you need to throw a SecurityException, you need to do a check against your locked map. To do this, you would need to write code in your Data Facade class such as;

public void update(int recNo, String[] data, long lockCookie) throws RecordNotFoundException, SecurityException { // long cookie = reservationsManager.checkRecLocked(recNo) // if (cookie == lockCookie { // database.update(recNo, data, lockCookie[] // } else { throw SecurityException }

thereby cluttering up your nice Data class.

So i have a few questions about this;
1. Is the lockCookie even relevant, when the application always uses a lock(), update/delete, unlock() sequence of calls, even in a multi-threaded test? is the lockCookie check only needed for unscrupulous updates or out of order lock/unlock calls such as a testing program.
2. Is this the correct approach? is putting such code in your Data Facade update/delete higher level OK? maybe it would be better to just put all the methods in one class and not use a ReservationsManager for lock/unlock in this case.
3. if so, is there still not the possibility that when update() and the checkRecLocked() method is called, another competing thread sneaks in and changes the lock map, so that cookie is no longer valid and is old, thereby giving you incorrect results, as the lower level protection of the map is not available in the Data class.
4. am i way off track here.

many thanks,

Hiya Roberto,

yes, i see your point:) it doesn't make much logical sense to do that - i'm probably just over thinking too much from the automated test program and an automatic failure viewpoint. I guess most people just hard-code a valid flag 0x00 and then write the rest of the fields for a create, and ignore completely for an update, so the arrays are matched in size.

so thanks for the clarification, i'll change it to just use the data fields. My original db file does not contain any deleted records, but i could just use a hex editor to set the deleted flag to test the 'create' method that first searches for a deleted record to replace.
thanks,

Hiya Roel,
Thanks again for your thoughts on this one,
as i'm working through the Data class now, and i'd interpreted it the opposite way, and give a few reasons why.

for your remarks;
1. include flag and all data as is in a create. why not? this is your low level FileDB class that is writing data to a defined schema, not the place to be doing any validation or logic. The flag is a 1-1 per record, so why would they even bother to include it at all if it shouldn't be written (as you say).
2. same.
3. agreed, you want to be consistent.

I suppose i'm looking carefully at the Data class from the automated testing viewpoint and what it would do. I'd have assumed they'd include this flag in tests as why would they go in detail of mentioning it at all. This mixes in with other threads that talk about the fact that the GUI requirements mean that you never even use the create/delete/update (other than owner field), but this does not mean you can get away with not implementing these methods. In the same way, just because the GUI requirements don't use the flag, i would have thought it doesn't mean you can get away with not creating/updating it in your low level DB class. I had designed to use a value object that makes use of a converter from the array -> value object and back, that will ignore this flag completely, because it is never used in your business or GUI layer.

Then again, you've passed so i might change it back:), (and i'm probably just annoyed as i've wasted 2 days figuring out about reading/writing unsigned bytes and getting the right charsets!!).

Thanks!
It sounds to me like either will pass sun's automated software test. If it does a read(0), it either works correctly and matches up the record, or throws a RecordNotFoundException, if so, checks read(1) and matches the record so either option is acceptable.

Just on this, have people passed with using both 0 and 1 as the starting number for recNo ?? As i'm wondering myself.
I would have thought this would be an important point, and not open to your own decision, as surely the automated testing program of your Data class would do a read(recNo) and match up against your submitted database. If your interpretation is wrong they would not match ...