Coming to implementation part, calculating the 30 min can be done using two ways.
Using the setTimeout function in JS and
Using Thread in Java layer.
Seems easier to simply record the lock expiry time with the other lock information in the database.
First step is to challenge the requirements.
Basically you can simplify the entire system by focusing on
The user can lock a record (record user identity and expiry time of lock; i.e. a lock is only valid if it hasn't expired yet), provided the record doesn't have a valid lock on it. A super user can override (overwrite) a normal user's lock (write (super) user identity and new expiry). Any user can only successfully modify the record if they have a valid lock on it - otherwise the operation fails. Note that there is no need to update the locking data on the record when the lock goes invalid. The passage of time will make the lock invalid. You will clear the locking data if the user intentionally releases the lock.
Now go back and say something along the lines: "What you are asking for is possible and nice but will take two, three, four times as long (as much money) as this solution" possibly followed by "which probably means that we won't be able to implement X which you really seem to want."
Its amazing how easily "non-essential" requirements are identified once the cost/effort comes into play.
Look for information on the
pessimistic offline lock.
Later on you can always add "equivalent" features by using AJAXish techniques. Expose a "service" on the web application that allows the JS client to get the remaining time on the lock (../locks/{username}/{recordname}/{recordid}) which the JS client calls every 120 seconds or so (most
Servlet containers don't like open HTTP requests to support "immediate client callbacks" unless they support continuations like Jetty). If the lock expires or is overwritten by a superuser the remaining time is 0 and a JS pop-up informs the user that the lock has been lost. If the remaining time is 4 - 6 min another JS pop-up is used to inform the user that the lock is about to be lost in m:ss minutes.