Last questions on Data class

[Pieter Jacobs]

Hi guys,

Man, I think I'm really spending too much time on the Data class now, but anyway:

1- I know a couple of you extended Sun's interface, but what about implementing Sun's and implementing my own too, instead?
2- Why when I create Threads in my Test class in a for loop and adding sleep(10) everything works fine, but when removing the sleep(10) statement, do I get errors e.g. "record * is not locked" etc.?
3- I have the "Bodgitt & Scarper" assignment and the (for instance) read() method should return a String[]. What have you guys done; meaning, are you sending the String[] etc. over the network, or have you done some changes to rather send a Value Object ?

Thanks,
Pieter

[Roberto Perillo]

Howdy, Pieter!

1- I know a couple of you extended Sun's interface, but what about implementing Sun's and implementing my own too, instead?

Hum... how would that be? You mean, having to classes implementing these interfaces separately? When you implement your interface that extends Sun's interface, then you are already implementing Sun's interface.

2- Why when I create Threads in my Test class in a for loop and adding sleep(10) everything works fine, but when removing the sleep(10) statement, do I get errors e.g. "record * is not locked" etc.?

Hum... I think we would have to see some code to be able to answer this one.

3- I have the "Bodgitt & Scarper" assignment and the (for instance) read() method should return a String[]. What have you guys done; meaning, are you sending the String[] etc. over the network, or have you done some changes to rather send a Value Object ?

Well, I think it depends on your choice between thin client and thick client. If you have a thick client, then it's pretty likely that the String array will be returned to the client side and handled there. If you have a thin client, then the String array will be transformed on the server side and sent back to the client in the form of a domain object (entity or value object). But both approachs are ok.

[Roel De Nijs]

Pieter Jacobs wrote:1- I know a couple of you extended Sun's interface, but what about implementing Sun's and implementing my own too, instead?

That seems a crazy idea to me Why would you do that? What will be the added value?

Roberto Perillo wrote:If you have a thin client, then the String array will be transformed on the server side and sent back to the client in the form of a domain object (entity or value object).

Exactly what I did

Kind regards,
Roel

[Pieter Jacobs]

Hi Roberto & Roel,

Thanks for the replies guys; I got so focused on trying to get everything perfect that as soon as things works fine, I read something different somewhere else, and then re-think what I'm busy with at that stage. Anyway, I'm gonna stick with the way I had everything and then ask more meaningful questions :-)

Thanks again and sleep well,
Pieter

[Pieter Jacobs]

Hi guys,

Excellent, now I can start with the server and gui; I created 200,000 threads and got it to insert a record each and all well - and damn fast too.

Have fun,
Pieter

[Roel De Nijs]

Hi Pieter,

Only creating new records is not a real challenge Mix some deleting, updating, creating together to have a lot of fun

Kind regards,
Roel

[Pieter Jacobs]

Hi Roel,

I only see now that I have not replied to your message as yet; yes, I've tried doing quite a few different things and all seem cool.

I got that test class off JavaRanch and modified it to work for my project and everything is 100's. I have pasted the results, so please shout if you see something funny:

9 trying to lock record #2 on UpdatingRandomRecordThread
10 trying to lock record #1 on UpdatingRecord1Thread
12 trying to lock record #9 on DeletingRecord1Thread
13 trying to find records
11 trying to create a record
9 trying to update record #2 on UpdatingRandomRecordThread
4 results found.
13 going to read record #0 in FindingRecordsThread - still 3 to go.
4 results found.
9 trying to unlock record #2 on UpdatingRandomRecordThread
10 trying to update record #1 on UpdatingRecord1Thread
12 trying to delete record #9 on DeletingRecord1Thread
13 going to read record #4 in FindingRecordsThread - still 2 to go.
4 results found.
13 going to read record #5 in FindingRecordsThread - still 1 to go.
10 trying to unlock record #1 onUpdatingRecord1Thread
4 results found.
13 going to read record #6 in FindingRecordsThread - still 0 to go.
Exiting for loop
12 trying to unlock record #9 on DeletingRecord1Thread

Thanks bud,
Pieter

[Roel De Nijs]

Hi Pieter,

This is kind of funny:

12 trying to lock record #9 on DeletingRecord1Thread

You should expect that this kind of thread tries to lock record 1 (instead of 9). Because that's just the big issue of this test case: DeletingRecord1Thread and UpdatingRecord1Thread which have to compete for the lock on the same record. And if you reuse record numbers when creating new records, then the CreatingRecordThread will create record 1 again and the 2 threads will again try to lock the same record (and so on until all iterations are completed). Thanks to this test your locking mechanism will be tested thoroughly and you'll know it works when it doesn't deadlock (when you use a high loop counter).

Kind regards,
Roel

[Pieter Jacobs]

Hi Roel,

Thanks for the quick reply!

I didn't mention; I have updated "DeletingRecord1Thread" with:

final int recNo = (int) (Math.random() * 10);

so that not only the first record are deleted all the time.

Thanks again for the reply!
Pieter