my dog learned polymorphism*
The moose likes Developer Certification (SCJD/OCMJD) and the fly likes My Choices Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login


Win a copy of OCA/OCP Java SE 7 Programmer I & II Study Guide this week in the OCPJP forum!
JavaRanch » Java Forums » Certification » Developer Certification (SCJD/OCMJD)
Bookmark "My Choices" Watch "My Choices" New topic
Author

My Choices

John Oconnor
Ranch Hand

Joined: Jan 12, 2011
Posts: 66

Hello for all!!
I want share in a general view my choices (in my txt file, are explain in more detail), if somebody want add a suggest, , will be accepted.

-conection type SOCKET selected, principal reazon, avoid work with threads;
Data base layer
-Cache: I have used cache, load when start the application, and refresh in every write operation in database file, principal reazon, avoid high data load with database file
-metadata information, i have created a class for maintan metadata information from database
GUI
-windows at start up: i have created a window where prepare the layout, common for the three options in who can init the application the user, each window enable or disable the components ( ex: in stand alone mode, only enable database file select, and disable port and hostname server for example)
-Panels, i have created a panel for each part in main window , example, a panel for search, a panel for jTable , and so. Is more easy to building and maintain .
-main window, the user only can exit via a option in a menu bar, avoid close acidentally.
-lock system, i have only lock the records when the user select a record in GUI , and select a action (reserv or delete), this lock is maintain until the user cancel or confirm the operation(delete or reserv)
- Register select. when the user select a register in GUI, this record is re-read from database file, and lock (at some time, ok almost some time jeje)
- i have add a panel with information for user in each window
-Room object, a room object who represent a record in database, to avoid work with array (such is indicate in DB interface) (add a constructor for Data[], and toArray() method)
-Exceptions, i have created a main exception, the exceptions defined in DB interface, are class who extends from this main exception
-exception handler, i have throws all to front end, to show information to user
-lock II, i have used lock on database file,for write,read operations, and all records blocks are maintain in a hashmap(i have considerate now change to concurrenthashmap for example)

this is all, may be add another choice(what do you think?). thanks for your time!!

Regards


SCJP 5 - OCMJD 6 - OCPJME1MAD(SCMAD)
Marcel van den Boer
Greenhorn

Joined: Apr 19, 2011
Posts: 21

John Oconnor wrote:conection type SOCKET selected, principal reazon, avoid work with threads;

Okay, last time I worked with Sockets (which admittedly is some time ago) I had to create a new Thread for every new connecting client. Do you really handle all requests on a single Server Socket? Doesn't RMI give you threading for free?

John Oconnor wrote:i have only lock the records when the user select a record in GUI , and select a action (reserv or delete), this lock is maintain until the user cancel or confirm the operation(delete or reserv)

What if the user does not cancel or confirm the operation? Will the lock hold forever? Other clients trying to lock that record, won't they then also wait forever too? If you only have a single Thread on your server, won't that client block new calls from every other client too, crippling your entire system?


OCPJP
Michael Enudi
Greenhorn

Joined: Apr 24, 2011
Posts: 20
The best bet in that situation as I am doing mine is to use the System.currentTimeMillis() to generate cookies and set an expiration for the cookie say for instance 60 * 1000 that is 1 min else a logic will be used to treat the lock cookie as expired even though the cookie is in the map.

Regards.
Marcel van den Boer
Greenhorn

Joined: Apr 19, 2011
Posts: 21

Michael Enudi wrote:set an expiration for the cookie say for instance 60 * 1000 that is 1 min

I don't think that would be the best solution. Do you think employees can enter the information in one minute? Maybe. Do you think clients like to wait a full minute (for each other client locking on that record) before getting the message "Sorry, the requested record does not exist any more!". Definitely not.

I think lock(), <verify_on_update>, <operation>, unlock() should be called immediately after each other, in the same method. This way, no lock is held longer than a fraction of a second. The only risk of keeping stale cookies would be when clients crash at the precise time they mutate a record (which is an exceptional case you could decide not to handle in your server).
John Oconnor
Ranch Hand

Joined: Jan 12, 2011
Posts: 66

Marcel van den Boer wrote:
John Oconnor wrote:conection type SOCKET selected, principal reazon, avoid work with threads;

Okay, last time I worked with Sockets (which admittedly is some time ago) I had to create a new Thread for every new connecting client. Do you really handle all requests on a single Server Socket? Doesn't RMI give you threading for free?

John Oconnor wrote:i have only lock the records when the user select a record in GUI , and select a action (reserv or delete), this lock is maintain until the user cancel or confirm the operation(delete or reserv)

What if the user does not cancel or confirm the operation? Will the lock hold forever? Other clients trying to lock that record, won't they then also wait forever too? If you only have a single Thread on your server, won't that client block new calls from every other client too, crippling your entire system?



Ok, OK a im some confusing, clear, the socket solution create a new thread by each client, so I can manager my lock for each register with this thread. So while the user is view the Register, until accept or cancel OR CONECCTION FAIL, this have lock this register.
So this user have "Forever" lock this record.

Too if add any other berhaivor, like lock for 1 minute, only this solution is more complex, and this is a bad approch, because, the easy is allways best, on a complex solution (and may be better).

I think who this is a engagement solution between both problems who you are indicate on my choices,
thanks!
John Oconnor
Ranch Hand

Joined: Jan 12, 2011
Posts: 66

Marcel van den Boer wrote:
What if the user does not cancel or confirm the operation? Will the lock hold forever? Other clients trying to lock that record, won't they then also wait forever too? If you only have a single Thread on your server, won't that client block new calls from every other client too, crippling your entire system?


Now i have change this, so how i am work with Socket, for each lock record, i have maintain the thread for lock. When another client try adquire a lock on a record, I have verify if any thread (getThreadGroup == null,returns the thread group to which this thread belongs is dead) is dead, so remove all threads who tread group is null, and can adquire the lock.

now, is better?
thanks
Marcel van den Boer
Greenhorn

Joined: Apr 19, 2011
Posts: 21

To be honest, I have some trouble understanding you. The points I'm trying to make are:

1. You motivate your use of Sockets by saying that it is easier to manage because you don't need to use Threads. I replied that this probably wouldn't be the case (and I think you confirmed this by mentioning you have a Thread for every client). Then I added that your current motivation would be more suitable if you chose to use RMI (because it creates the Threads for every new connection automatically). So my advice is: Write a better motivation for the use of Sockets.

2. You seem to call lock() on a record and then allow the GUI to maintain that lock indefinitely if not another button is pressed. I expressed my concerns about this approach by asking you how other clients will respond to this situation. My opinion is that you should keep a lock as short as possible (less than a second), to avoid any wait times at other clients which are interested in the same record. But you may have your reasons to do it differently. If you know that your other clients will behave without problems, then explain how that works in your CHOICES.TXT.

And to your latest reply:
If I understand you correctly, you now have added some logic which will make a record available again if the Thread which has locked it has died before giving up the lock. You may have worked around some of the symptoms, but I don't think this resolves any of the issues I raised (but then again I do not know how exactly you have set up your server). Test your code thoroughly and explain it in your CHOICES.TXT

So, in short:
Be sure that your CHOICES.TXT reflects your work. In it, describe if, how and why your application will handle some uncommon situations like a client crashing. And most importantly make sure your application works according to the specifications.
Michael Enudi
Greenhorn

Joined: Apr 24, 2011
Posts: 20
Marcel van den Boer wrote:
Michael Enudi wrote:set an expiration for the cookie say for instance 60 * 1000 that is 1 min

I don't think that would be the best solution. Do you think employees can enter the information in one minute? Maybe. Do you think clients like to wait a full minute (for each other client locking on that record) before getting the message "Sorry, the requested record does not exist any more!". Definitely not.

I think lock(), <verify_on_update>, <operation>, unlock() should be called immediately after each other, in the same method. This way, no lock is held longer than a fraction of a second. The only risk of keeping stale cookies would be when clients crash at the precise time they mutate a record (which is an exceptional case you could decide not to handle in your server).


I may not have explained it very well but the basic point is to always call unlock() after every operation. But incase of a client crashing in the middle of lock() - unlock(), the record should not stay long forever. So using a time constant to check how long a record has been locked who help indentify expiration.
Roel De Nijs
Bartender

Joined: Jul 19, 2004
Posts: 5445
    
  13

Marcel van den Boer wrote:
John Oconnor wrote:conection type SOCKET selected, principal reazon, avoid work with threads;

Do you really handle all requests on a single Server Socket? Doesn't RMI give you threading for free?

Yes, it does! So that's simply a bad motivation (as you already indicated).


SCJA, SCJP (1.4 | 5.0 | 6.0), SCJD
http://www.javaroe.be/
Roel De Nijs
Bartender

Joined: Jul 19, 2004
Posts: 5445
    
  13

John Oconnor wrote:-lock system, i have only lock the records when the user select a record in GUI , and select a action (reserv or delete), this lock is maintain until the user cancel or confirm the operation(delete or reserv)

Also already indicated by Marcel, but I'll agree with him. That's just a bad approach. You should always try to keep the time a record is locked to a strict minimum. Now you are even locking a record even if it's not needed (user cancels the operation). So when the user confirms the operation, you should lock the record, update/delete it and finally unlock it.
Roel De Nijs
Bartender

Joined: Jul 19, 2004
Posts: 5445
    
  13

Michael Enudi wrote:I may not have explained it very well but the basic point is to always call unlock() after every operation. But incase of a client crashing in the middle of lock() - unlock(), the record should not stay long forever. So using a time constant to check how long a record has been locked who help indentify expiration.

If you make sure that the time a record is locked, is kept to a strict minimum (that is: start the whole process when user confirms the booking), then a client crash would be very rare in the middle of the operation, so that's unlikely to happen. If you even use a thin client approach, the above scenario is impossible. So you are adding extra complexicity to your program which is not needed at all if you have a good design.
And as a final note: because it's done like that in the SCJD book (by Andrew Monkhouse) is not a reason to incorporate a similar solution in your application (because the instructions of Denny's DVD differ from the OCMJD instructions). The code in the book even violates one of the must requirements to prevent you from just copy/pasting the complete solution, so you'll fail automatically (more info can be found in this thread).
John Oconnor
Ranch Hand

Joined: Jan 12, 2011
Posts: 66

Marcel van den Boer wrote:

2. You seem to call lock() on a record and then allow the GUI to maintain that lock indefinitely if not another button is pressed. I expressed my concerns about this approach by asking you how other clients will respond to this situation. My opinion is that you should keep a lock as short as possible (less than a second), to avoid any wait times at other clients which are interested in the same record. But you may have your reasons to do it differently. If you know that your other clients will behave without problems, then explain how that works in your CHOICES.TXT.


When another client try take some registry who i am lock, they obtain a info message, where is indicate who registry is lock.
I made a question, when I select a result, I can press Reserv or delete, so a new dialog is show (at this moment the registry is lock, beacuase the user will have who confirm), will be needed show a new dialog for make a reserv or delete? , or this is a error, and I only need select a registry and select Reserv or Delete, and directly confirm this action, (so the lock is almost instant, and unlock when the transaction is made)


now i have search-select in jtable-reserv or delete - show record in a new dialog(at this moment are locked) - confirm or cancel and release lock- back

so i should made search-select in jtable - press reserv or delete(and directly made the reserv or delete action with out a new dialog)


Another question, i don´t worry about the customer id? , this value i am give in the confirm dialog, i am wrong?
Roel De Nijs
Bartender

Joined: Jul 19, 2004
Posts: 5445
    
  13

You should always try to keep your lock-time as short as possible, so when user confirms the update you start the whole process (lock/update/unlock) is better than already locking the record when it's selected by the user from the JTable

I validated the customer id to be an 8-digit number as the instructions stated it should be an 8-digit number.
Michael Enudi
Greenhorn

Joined: Apr 24, 2011
Posts: 20
If you make sure that the time a record is locked, is kept to a strict minimum (that is: start the whole process when user confirms the booking), then a client crash would be very rare in the middle of the operation, so that's unlikely to happen. If you even use a thin client approach, the above scenario is impossible. So you are adding extra complexicity to your program which is not needed at all if you have a good design.


Thanks for the Monkhouse note. But I think it is rather contentious a bit given this scenario

as opposed to


The optimistic locking in JPA that is achieved by using the @Version on a column designed for that purpose informs my decision on using this approach.
The time limit on the lock cookie duration on the other hand was I idea I got from Monkhouse to avoid holding the lock forever incase of a crash/power off in between the client calls.
John Oconnor
Ranch Hand

Joined: Jan 12, 2011
Posts: 66

Roel De Nijs wrote:You should always try to keep your lock-time as short as possible, so when user confirms the update you start the whole process (lock/update/unlock) is better than already locking the record when it's selected by the user from the JTable

I validated the customer id to be an 8-digit number as the instructions stated it should be an 8-digit number.


well, now i made the next,

-select a register in table
-obtain from database
-accept reserv
-lock the registry
-verify if the before register have not a customer id
-update
-unlock

I have lock-unlock from GUI, but now i think qho i can made this operation fully in back end, because is minnor the risk in a delete or reserv operation. Too when the operation is confirmed, this is a atomic operation. (almost instant), don´t worry about if the client crash!. Now the server is who responsible for transaction.

Thanks for all!
Roel De Nijs
Bartender

Joined: Jul 19, 2004
Posts: 5445
    
  13

Michael Enudi wrote:The optimistic locking in JPA that is achieved by using the @Version on a column designed for that purpose informs my decision on using this approach.
The time limit on the lock cookie duration on the other hand was I idea I got from Monkhouse to avoid holding the lock forever incase of a crash/power off in between the client calls.

Maybe you should reconsider the update process and you should implement something like:
a) lock
b) verify if record is still available
c) update or throw an exception (depending on the result of b) as you don't want to have double bookings)
d) unlock

John Oconnor
Ranch Hand

Joined: Jan 12, 2011
Posts: 66

Roel De Nijs wrote:
Maybe you should reconsider the update process and you should implement something like:
a) lock
b) verify if record is still available
c) update or throw an exception (depending on the result of b) as you don't want to have double bookings)
d) unlock



Clear, i have made the change, and now when the user confirm the reserv in these moment :
a) lock
b) verify if record is still available
c) update or throw an exception (depending on the result of b) as you don't want to have double bookings)
d) unlock

or when delelte a record, the user confirm delete,

a) lock
b) verify if record is still available
c) save in database as delete record(delete logically)(or throw a exception if already delete)
d) unlock

All operations are made in back end.

My lock unlock is in a try/finally, for avoid who any exception avoid released the record locked
Roel De Nijs
Bartender

Joined: Jul 19, 2004
Posts: 5445
    
  13

John Oconnor wrote:or when delelte a record, the user confirm delete,

a) lock
b) verify if record is still available
c) save in database as delete record(delete logically)(or throw a exception if already delete)
d) unlock


First of all: delete functionality is not required in your GUI and you won't receive any credit for doing that.

Secondly: when a record does not exist anymore, because it was already deleted, I would expect the lock-method to throw a RecordNotFoundException, not the delete-method itself.
John Oconnor
Ranch Hand

Joined: Jan 12, 2011
Posts: 66

Roel De Nijs wrote:
First of all: delete functionality is not required in your GUI and you won't receive any credit for doing that.

Secondly: when a record does not exist anymore, because it was already deleted, I would expect the lock-method to throw a RecordNotFoundException, not the delete-method itself.


OK, i do not have 100% sure if delete is a needed option in GUI. The only option in GUI for room selected will be Reserv.

Ok 2nd, because the lock method throws RecordNotFoundException, so i can before lock, know if already is a valid record in database.

I am some hard
John Oconnor
Ranch Hand

Joined: Jan 12, 2011
Posts: 66

Roel De Nijs wrote:
Marcel van den Boer wrote:
John Oconnor wrote:conection type SOCKET selected, principal reazon, avoid work with threads;

Do you really handle all requests on a single Server Socket? Doesn't RMI give you threading for free?

Yes, it does! So that's simply a bad motivation (as you already indicated).




Hey, i have find here in forum, books and another sides, at summary my choice for Socket solution is the nex:

So socket solution can be very simple and easy,
who in case of maintain this solution at long time, can will
go adding best behavior solve more robust and eficient.


Well , in my choice, this is the final argument, but i have write in detail and explain each point in where I have justified my choice.

Because, you DONT BELIEVE who only this IS My CHOICE about socket, this is the final words.( in my choice too there are about 35 lines whit all details jejeje, in my choice.txt)

Regard
 
I agree. Here's the link: http://aspose.com/file-tools
 
subject: My Choices