• Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other Pie Elite all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Jeanne Boyarsky
  • Ron McLeod
  • Paul Clapham
  • Liutauras Vilda
Sheriffs:
  • paul wheaton
  • Rob Spoor
  • Devaka Cooray
Saloon Keepers:
  • Stephan van Hulst
  • Tim Holloway
  • Carey Brown
  • Frits Walraven
  • Tim Moores
Bartenders:
  • Mikalai Zaikin

Warning to a client about data changes.

 
Ranch Hand
Posts: 50
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
I'm building a system where the clients could be Java GUI Applications and Java Web Applications. I'm going to use Weblogic 6.1 SP1 as the AS.
The technologies to be used are EJB 2.0, Servlets, JSP, JMS, etc.
The issue is that I have to manage the concurrency between readers and writers. I mean, if a client make a query, and get some data from the DB, and if meanwhile the data are in the screen, another client modify the information
-thru an EntityBean-, I have to warn the reader client about the changes.
Somebody knows about some technology (from Weblogic, or a third party product), that permits me to do that?
Thanks in advance.
Cristian
 
Author
Posts: 25
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Typically, this is not something you should worry about. It is commonly understood that data on a screen is stale the moment after it is queried. The user normally has no expectations that the data will remain the same (i.e., that some other user isn't modifying the data).
The solution for cases where you need logical record locking are to implement features that permit just that. For example, if your application was a database full of memberships, you would have a button that said "Lock this membership" so that you can edit it. Then, you would implement application-level entity locking.
But again, if you design your roles and responsibilities correctly, this is often not a problem. For example, on JavaRanch, I know that only I and an administrator can edit my profile (at least I hope so!). I have no expectation that while I am viewing my profile data that noone is behind the scenes editing it. Administrators, generally, know what each other is doing (there should not be too many administrators) and/or have domains of administration.
It's only in cases where you have many administrators without well-defined boundaries that you need application-level record locking support.
 
Cristian Cardenas
Ranch Hand
Posts: 50
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Thank you very much Greg.
I think that is near to impossible or at least very expensive to implement that kind of feature,
but it's a requirement of the system. So, I'm going to use your answer to dissuade my boss about this issue.
Best regards.
Cristian.
 
Roger Thornhill
Author
Posts: 25
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Hi Cristan,
Just a quick followup. I didn't want to come across as if there was never a case for application-level record locking. There is. You see it a lot in places where many people have administrative access to a common piece of data (ie, your registration information at school, your patient record at a hospital, etc). At such places, it is sometimes the case that an administrator wants to edit that record, but cannot because another admin is editing it.
But, even in these types of scenarios, there is still no expectation -- for those just viewing data -- that the current data on their screen is still valid. The only time that is the case is when the very operation they are doing (e.g., edit) guarantees that. Now, it might be possible for someone to demand that "viewing" requested data also locks that data, but it is not a common requirement and it would seem (at least to me) that the application would be frustrating to use, especially in places like a hospital or school etc.
Anyway, I just wanted to clarify that point. Also, if you do want to implement application-level record locking, you don't necessarily need to have a "Lock" button. The very nature of the operation (e.g., edit) might necessitate locking, so the "edit" button would actually correspond to "lock this record and go into edit mode".
Anyway, hopefully this clarification has helped more than it hurt.
 
reply
    Bookmark Topic Watch Topic
  • New Topic