• Post Reply Bookmark Topic Watch Topic
  • New Topic

User Defined Global Object accessable by all in container  RSS feed

 
DC Dalton
Ranch Hand
Posts: 287
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I am working on a servlet driven application in Resin 3.10 and have hit something Ive never tried before, hence my question.. first some details.

The app Im working on is required to do a "quasi lock" on Postgresql tables ROW ...... I say quasi because they want to be able to go into a persons profile (employment type stuff) and browse, read it, and MAYBE edit it. Well of course with more than one person able to do this problems could mount up fast..... BUT they dont want the row actually locked down or the table locked down until they go into edit mode. Even then they have told me they may spend HOURS on the phone with a client updating and editing their data. So we cant just lock down the tables..

what I decided was to build an object that has a static container object that has the locked down rows and which user has the lock in it. This way on the front end NOT the db I can stop others from editing data that may be already being edited (it will become readonly on the front end) so I created this object and then started wondering how in the heck Im going to make it global to all the users. I saw in the API that you can add things to the ServletContext with the setAttribute(java.lang.String name,java.lang.Object object) method.

So to my question .... in the init method of the main controller can I create this custom object and then add it to the Context and if so will it then be available to ANY servlet within the application or just within the scope of the main controller. There are other servlets that run within the scope of the app an I wanted to make sure I can get the object there too!

Thanks in advance and if what Ive mentioned here WONT work anyone have other ideas? Im all ears!
 
James Carman
Ranch Hand
Posts: 580
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Why don't you try using optimistic locking? You would have to add a column to the table you're trying to lock to keep the "version" or whatever you want to call it. Search the forums for a description of optimistic locking or Google for it.
 
DC Dalton
Ranch Hand
Posts: 287
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Yes we had thought of that possibility but the scope of any lock is (usually) a transaction ..... and transactions arent going to happen with this guy!

This client is a bit of a "twitchy bird" who has been doing things "his way" for years and treats this app as a piece of paper, so to speak. I talked to him about the "edit mode" functionality where someone has a lock on some row of data (a candidate) ..... and he just wants to be able to spend as much time as possible editing it and no matter HOW long he takes he wants that candidates data locked down! It was bad enough it took me two days to explain WHY you dont put two fields worth of data in one field .... the transaction thing just flew right over his head. ..... so its a "give the client what he wants" type situation, luckily there are only three employees able to access the app at one time!

Im pretty sure that within a month or two he will complain about the lock and we'll then have to do something else but for now Im REALLY sick of trying to explain these concepts to him because he just doesnt get them.
 
James Carman
Ranch Hand
Posts: 580
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
How about putting an extra column on the record stating who is the "editor" of that record? I assume you have some concept of users in the system. So, in your GUI, you could have an "edit" button which shows up if there is no editor assigned to the record. If there is an editor assigned, then maybe you could show their name. When the editor saves his/her work, then clear the editor property. Does that sound reasonable? That way, it's stored in the db and you don't have to come up with some elaborate locking strategy.
 
DC Dalton
Ranch Hand
Posts: 287
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Yes we have a timestamp "last updated" and an "edited by" field in the db .... what I had thought was when someone does try to go into edit mode on a locked candidate and the row WAS locked down I would take away their ability to change any data (actually just remove the submit button) and also give them a notice saying something like "Candidate currently being edited by blah blah" .. that way if someone locks a row and walks away and someone else needs to get into it they can call or IM them (the offices are in 3 different places - hence the web app) and ask them what they are doing!

We actually wanted to build this using XMLHttpRequest on each field so you could just double click the field, edit and hit enter but when you add the problems this guy is already creating that would have been a nightmare!

Ahh the fun of multi office systems and clients who dont have a clue!


BTW, I just ran some tests on putting an object into the ServletContext and so far so good!
 
DC Dalton
Ranch Hand
Posts: 287
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
OH I just re-read your post and I see what you mean! In other words when they pull the data we put the username in and then when they submit you remove it! Actually thats not a bad idea!
 
James Carman
Ranch Hand
Posts: 580
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Thanks! I come up with them every now and then. I'm gonna go mark my calendar!
 
DC Dalton
Ranch Hand
Posts: 287
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
HMMMM .... man you've got me thinking here! Im just considering whether another hit to the db or to an object is more functional and practical .... anyways THANKS MUCH for the alternative idea! GREAT STUFF!
 
James Carman
Ranch Hand
Posts: 580
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Let me know how it works out. I'd be interested to know. It sounds like a fairly simple/reliable way to solve your problem whether you use a db or not.
 
Sripathi Krishnamurthy
Ranch Hand
Posts: 232
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
James,
isnt ServletContext a better option here? I think using another column in DB is another option, but setting objects in context is very simple. And ServletContext is designed so that all servlets in the web application can use it. And what else can be the use of ServletContext if one doesnt use its features. Just setAttribute and getAttribute would be simple.
I think using DB will make things a bit complex although the functionality can be achieved.
Do you agree with this or have I missed anything here?
 
DC Dalton
Ranch Hand
Posts: 287
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Yup I agree ..... and I decided to go with the ServletContext idea .... it really was quite simple once I read a bit and yes you are right, ALL the objects within the app can get to it an access it!
 
James Carman
Ranch Hand
Posts: 580
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
One problem with using the servlet context is that you can't share that with other applications which need to use the same data (with the locking mechanism). Also, a lock will not persist when the server shuts down or the webapp restarts. I don't know if it's necessary to support such a thing, but you might want to be able to let a user lock something down to work on it for a week or something. Anyway, the servlet context version will work and I'm glad the idea helped out.
 
Sripathi Krishnamurthy
Ranch Hand
Posts: 232
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I didnt think of the two cases

1) servletcontext wont work when there are multiple web applications running under different context. (this has to be considered while designing)
2) when the server crashes, context will be no more available. (when the server crashes nothing will be available..context, session, config etc. So ideally an application cannot be designed to handle server breakdown).
But in this case, assuming that there is a DB lock, will the Db lock not persist and continue to be persist even when the application comes up? This could be dangerous since edit can never be done when the server crashes and db lock continue to persist.

But yes, one has to consider all possibilities.
James, you really think out of box. great..
 
  • Post Reply Bookmark Topic Watch Topic
  • New Topic
Boost this thread!