Win a copy of The Business Blockchain this week in the Cloud forum!
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic

Data Server

 
Adrian Yan
Ranch Hand
Posts: 688
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
From my requirement, isn't the data server same as the RMI server?
 
Matt DeLacey
Ranch Hand
Posts: 318
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I have just now completed the Data Server portion of the project, and that is the case with me, although mine is a work in progress. Of course, if you used Serialized Objects over a Socket, I guess this would not be the case. Also, I expect that things will change somewhat as I work toward making my project threadsafe, although I don't anticipate this changing the fact that my remote data server is my rmi server.
Hope this helps.
With Respect,
Matt
 
Adrian Yan
Ranch Hand
Posts: 688
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Yes, thanks.
From your post, I'm not sure what you mean by making it thread safe. I assume you mean the lock and unlock mechanism. I read my requirement many time, and put alot of thinking into this topic, I just can't seem to come to the conclusion of how to handling thread safe. In fact, I don't see it in my project that thread safety will become an issue (besides the locking and unlocking, which should be handled correctly to avoid data curruption.)
The basic requirement of the project is to create a client and server, local and network mode, booking, searching, locking and unlocking.
It's obvious that the local mode has not concurrent access problem. Searching won't compromise the integrity of the data. Booking is just a write method sandwiched between lock and unlock, if the locking and unlocking is handled properly, booking will be fine.
Lock and unlock is a write lock, which means that they can corrupt data dued to concurrent accessing. If they are designed properly, thread safety won't be a big deal.
All other methods involves reading, they don't cause any problems even if under multiple concurrent access.
That's IMHO.
Any thoughts on these?
 
Matt DeLacey
Ranch Hand
Posts: 318
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Yes, when I spoke of making it threadsafe I was talking about the locking and unlocking. I think there is the opportunity for problems too if you are booking and don't obtain a lock before you read to see how many seats are available. If you don't obtain the lock, you could do a dirty read, and tell the user there are not enough seats when that is false or that there was a seat when there wasn't. I haven't put a lot of thought into yet, but as soon as I clean up everythin else (about 1 week), then I'm going to tackle it, but I definately think you'll need to obtain a lock before reading when booking as well...so as not to do a dirty read.
With Respect,
Matt
 
Matt DeLacey
Ranch Hand
Posts: 318
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Oh yeah,
I agree that right now I can't see what all the fuss is about in terms of locking but I'm AFRAID that that's just because I haven't tackled it yet. When reading SCJD newsgroup posts, it seems like 75% or so of the discussion is on the locking. If it were no big deal, I wouldn't think it would generate as many questions as it does. The other thing is: I believe that that is one of the biggest things Sun is going to look at (let's face it, VERY few people are going to fail based on the GUI or just the logic in general), AND to me it seems like it's going to be somewhat difficult to test. When I think about what kinds of tests I'm going to have to write to convince myself 100% that I'm doing all the locking and unlocking properly, I begin to lose some sleep Also, I'm not sure if it's true, but I've rad in the newsgroups about people who actually scored high enough to pass (>=125/155 I think) but Sun failed them because everythig wasn't threadsafe. I THINK they had the opportunity to repost their solution, but still...

With Respect,
Matt
 
Adrian Yan
Ranch Hand
Posts: 688
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
If what I did was correctly, using hashset and wait(), notifyAll(), then it should not be that complicated. I think one of the biggest issue is that some people are reading way too much into the requirement. For example, biggest thing I think is the tracking of client id. Personally, since I'm putting all my lock, read, update, write, unlock mechanism is my client code (not yet implemented, but that's my plan).
Since the responsibility of this is in client code, it allows loose coupling of systems, reuse the server code, future enchancement, etc. Because the client will handle this, there is no reason the server should keep track of the client id.
In the client part, the method for booking should contain the lock mechanism, as far as available seat number and stuff. The client needs to check (read) available seats from server first, if unavailable, then the client should warn the users. This way, it's faster (less interaction), safer (no data corruptions).
As for Matt's comment for dirty read, in my requirement, it stated that if update occur to a record while being displayed by another client, no change occurs to the client.
 
Matt DeLacey
Ranch Hand
Posts: 318
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
It's true that your client display can DISPLAY a dirty read(i.e. when you successfully book, you don't have to broadcast to all clients to makew them update their displays), but you are not allowed to tell a user that they successfully booked a flight when there was not a seat available for them to book, nor can you tell them that there are not enough seats available when there are. Both of these events can happen if you do a dirty read, which you will if you don't acquire a lock before reading how many seats are available from the db. Actually, the second event won't happen for us because there isn't the functionality to cancel a booking, but it's easy to imagine that they would in the future, and besides, the first can happen so might as well prevent both. Just my opinion.
With Respect,
Matt
 
Adrian Yan
Ranch Hand
Posts: 688
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Booking failure because of a dirty read is definitely a problem. I think I got your point Matt.
I think my FBN assignment is somewhat different than yours (I hope). My understaning of booking is nothing but a lock, READ, update, write, unlock mechanism.
For example:
One flight has 2 seats available.
ClientA is doing a booking, it successfully locked the Hashset
ClientB is now starting the booking process, it has to wait because the lock is held by clientA at this time.
ClientC is now also start the booking process, it also has to wait.
ClientA needs to book 3 seats, since it has the lock, now it does a read, (which has 2 seats), so it gets a warning that no seat avialable for the booking. It exits, and it releases the lock at this time.
ClientB now gets the lock (no neccessarily in this order). It needs to book 2 seats. It now does a read, (which has 2 seats), proceed to update the record, then write the record, everything goes fine, it releases the lock.
ClientC now gets the lock, it needs to book 1 seat. It does a read, (which has 0 seats). It will get a warning, exit the booking method, and release the lock.
Since the requirement mentions nothing about rollback, or commit handling, I am not sure about what to do if write() method fails.
Any ideas, Matt!?
 
Matt DeLacey
Ranch Hand
Posts: 318
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Adrian--
Seems to me that your ideas are sound. If the write fails, it SEEMS like to me that you still have the lock, so you just throw some DatabaseException back and report it in the GUI and that one particular thread's request fails as if it were never even made, and when it releases the lock all is well again? I'm not sure what the problem there would be.
With Respect,
Matt
 
Adrian Yan
Ranch Hand
Posts: 688
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Matt, I think that's what all the problem regarding booking everyone been talking.
My theory on this is the following: (Peudo code)
public boolean book(int recnum){
try{
1. Do the lock(int recnum);
2. Do the getRecord(int recnum);
3. Do the verification to ensure the available seat;
4. Update the record;
5. Write the data using write(String [] updatedData);
} catch(execeptions here){ //maybe more than one
} finally {
6. Do the unlock(int recnum);
7. call the invariant() to guanrantee the db is still in good condition.
//maybe some more clean up here
}
}
As you can see Matt, the unlock() method is guarantee to execute, if lock() failed (bacause exceptions, not because of blocking), the execution of unlock() does nothing.

 
Matt DeLacey
Ranch Hand
Posts: 318
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I agree. Your ideas are sound. Good luck.
With Respect,
Matt
 
Adrian Yan
Ranch Hand
Posts: 688
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Good luck to you too.
Thanks for helpful informations, Matt!
 
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic