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
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.
posted 16 years ago
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.
posted 16 years ago
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.