*
The moose likes Developer Certification (SCJD/OCMJD) and the fly likes About the GUI and locks Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login


Win a copy of Android Security Essentials Live Lessons this week in the Android forum!
JavaRanch » Java Forums » Certification » Developer Certification (SCJD/OCMJD)
Bookmark "About the GUI and locks" Watch "About the GUI and locks" New topic
Author

About the GUI and locks

Luiz Reginaldo Curado
Ranch Hand

Joined: Jan 19, 2006
Posts: 108
Hi!

I'm designing my application by using a frame that shows the records returned by the searh and another frame that is presented when user selects a record and press the "update" button.

My question here is: when I show the "update" frame must I lock the selected record? This approach could stop some client threads until the one that is updating the record releases the lock. If this one go to have a cofee, the application response time will be not good... What you think?

Also, are you all designing your application using two frames too?

Thanks!

Luiz Reginaldo
Petr Hejl
Ranch Hand

Joined: Feb 26, 2006
Posts: 68
Never do it this way! It is a very very bad practice.
Luiz Reginaldo Curado
Ranch Hand

Joined: Jan 19, 2006
Posts: 108
Hi, Petr.

What is bad, have two frames or lock before show the update frame?
Petr Hejl
Ranch Hand

Joined: Feb 26, 2006
Posts: 68
To have user dialog covered by db transaction. You should execute transaction when user perform some action (like book, execute, whatever) and immediately finish it.

You should collect data from user and after this perform transaction with all needed inputs. Do not open transaction for "user thinking".
Luiz Reginaldo Curado
Ranch Hand

Joined: Jan 19, 2006
Posts: 108
Petr,

In my case the frame is not a dialog. To be more specific, I present a table to user in a JPanel and when a record is selected I present another JPanel containing the record data. This second JPanel appears in place of the first. Like this:

JPanel with JTable ----------------> JPanel showing record data
update button


JPanel showing record data ----------------> JPanel with JTable
confirm button

What I'm saying is to perform a lock in the record when pressing the update button, and unlock the record when pressing the confirm button.

Is it a good idea? Are you ranchers doing the same?

Thanks!

Luiz Reginaldo
Roy Mallard
Ranch Hand

Joined: Jul 14, 2005
Posts: 53
I think it is better to keep records locked for as short a time as possible. This will minimize interference with other clients.

It sounds like you are trying to prevent another client from modifying the record that this client is just about to modify.
It might be better to just allow that situation, and show an error message saying that the record has changed.
You can easily detect if the record has been modified by another client by maintaining a modification timestamp for each record.


SCJP 1.4<br />SCJD
Petr Hejl
Ranch Hand

Joined: Feb 26, 2006
Posts: 68
Yes thats my opinion. No matter how your dialogs are ordered. You should never require user interaction inside of db transaction.
Luiz Reginaldo Curado
Ranch Hand

Joined: Jan 19, 2006
Posts: 108
Hi, thanks for your comments!

Let's forget my idea and analyse the following scenario, as suggested:

- Client A selects a record, the update screen is showed (no locks)
- Client B selects a record, the update screen is showed (no locks)
- Client A update the record (lock, update, unlock)
- Client B update the record (lock, update, unlock)

I have a doubt, however. You suggest report a message to user B to say that the record was updated (it was done by client A). But the assignment says:

// If the specified record is already locked, the current thread gives up
// the CPU and consumes no CPU cycles until the record is unlocked.

Assuming that I report a notification message to user B, and not commit your update. In doing it, am I not breaking the assignment rule?

Comment, please!
Petr Hejl
Ranch Hand

Joined: Feb 26, 2006
Posts: 68
You mix two things together. The wait clause is mentioned with lock method and does not have to do anything with lock;read;update;unlock cycle. In your scenario, client B would perform lock;read;(see changed record)unlock; It is not related to waiting inside of lock method in any way.
Luiz Reginaldo Curado
Ranch Hand

Joined: Jan 19, 2006
Posts: 108
Thanks for your reply, Petr. I took the idea.
But then, in the case:

- Client A selects a record, the update screen is showed (no locks)
- Client B selects a record, the update screen is showed (no locks)
- Client A update the record (lock, update, unlock)
- Client B update the record (lock, update, unlock)

Client B will overwrite what A had done??? Is it ok to the assignment???

I'm very confused about that in the assignment...
Petr Hejl
Ranch Hand

Joined: Feb 26, 2006
Posts: 68
You should implement lock;read;update;unlock; not lock;update;unlock.
Read operation serves for consistency check - you compare actual state of record with the record in database and check if it was modified. If so you raise some exception and unlock (withou any update).
Luiz Reginaldo Curado
Ranch Hand

Joined: Jan 19, 2006
Posts: 108
Yes, I think this is a good idea.

Thanks!
 
jQuery in Action, 2nd edition
 
subject: About the GUI and locks
 
Similar Threads
A question about deletion and RMI
Row locking using oracle database
Locking Oracle Record
NX: (Contractors) Interfaces and design question
DBMain interface: lock - delete - unlock or lock/unlock within delete?