Discussions

EJB design: DAO: how to avoid lost update?

  1. DAO: how to avoid lost update? (11 messages)

    Hello!
    I would like to use the DAO Pattern to decouple my business logic from my persistence logic. There is just one problem I'm not sure how to solve:
    1. I call a read DAO method, which loads the data I need from the database and gives me back a DTO.
    2. I do something with this data and modify it.
    3. I write it back by calling an update DAO method.
    If I have more than one user, how can I avoid the lost update problem? Executing these steps in parallel I could end up losing an update.
    I could implement my own optimistic locking, but isn't there a better way?

    Thank you very much for any suggestions or links,
    Jonas

    Threaded Messages (11)

  2. How is an update going to be "lost"? Why would two different users ever need to update the same record? I think locking records is a waste of time. Generally, a system where multiple users are updating the same record indicates a poor data model.
  3. How is an update going to be "lost"? Why would two different users ever need to update the same record? I think locking records is a waste of time. Generally, a system where multiple users are updating the same record indicates a poor data model.
    I think there are many situations where users need to update the same data. Think about two bidders on Ebay or two programmers working on the same source code.

    Regards,
    Jonas
  4. How is an update going to be "lost"? Why would two different users ever need to update the same record? I think locking records is a waste of time. Generally, a system where multiple users are updating the same record indicates a poor data model.
    I think there are many situations where users need to update the same data. Think about two bidders on Ebay or two programmers working on the same source code.Regards,Jonas
    Two bidders on Ebay should not update records, period. They should do inserts only. If two bidders submit bids at the same time, one of them will be recorded first and one of them may be a higher bid. The system should be smart enough to query for the latest and/or highest bid, whatever the business rules are. There is no need to update any records.

    If you insist on updating records then you will be back at forums like this asking "Which is better, pessimistic or optimistic locking?".
  5. Why would two different users ever need to update the same record?
    Well, I've read several posts of yours, Race Condition. This is, by far, the most dumb of them (even considering the one about some Michael Moore movie).
    I wonder if you ever worked on a real project.
    There is plenty of reading material out there, in case you dislike college. I suggest you get a grip on some... FAST.
    Man, you are realy a pain. If you don't like belonging to a community, then don't. There are people out there who, unlike you, want to learn.
    I most certainly will not dignify your bad tempered posts with an argument.

    Jonas: if you have concurrency issues in the persistence layer, then the usual solution IS optimistic locking. And, being a professional developer (unlike our good friend Race), you indeed should consider the possibility of two users updating the same record. The commmon scenario is not about two transactions performing updates on the same record at the same time, but about stale data. It's a problem that arises when you use the value object pattern, for instance.
    So, my opinion is: yes, you can use optimistic locking.

    Regards
  6. The commmon scenario is not about two transactions performing updates on the same record at the same time, but about stale data. It's a problem that arises when you use the value object pattern, for instance.So, my opinion is: yes, you can use optimistic locking.
    Thanks again for your reply. I'll go ahead with optimistic locking then. :-)

    Regards,
    Jonas
  7. Jonas,

    I apologize for sounding so gruff. However, I want to make the point that good data modeling is the most important aspect of any IT project. If the database is modeled correctly, the code will be very simple and straightforward. The example with EBay is meant to demonstrate that the bidding system should be modeled to record all transactions with an insert. This makes the system easier to audit and the code will be simpler.

    If you are on a project where you have no control over the database schema and the DB schema stinks, then you may have to compromise your code.

    CHEERS!
  8. Hey Martin? How much did you gross last year as a "professional" developer? As a dumb, unprofessional I made over $138,000. So while you were agonizing over locking records I was delivering better solutions, faster - and my clients are very happy.
  9. My bad, Race. I now understand that, being a millionaire, you are not dumb. Dumb people with a lot of money are better called "excentric".
    I'm very sorry. No need to send your personal army; got the message: if you make a lot of money, you MUST to be good at it. Thanks a lot for putting me back on track.
    I shall spread your word.

    Regards,
    Martin
    (aka: the poor dude with a humble computer)
  10. How is an update going to be "lost"? Why would two different users ever need to update the same record? I think locking records is a waste of time. Generally, a system where multiple users are updating the same record indicates a poor data model.
    See Four Concurrency Problems<br> .
    /Gianluca
  11. I could implement my own optimistic locking, but isn't there a better way?
    Hi Jonas!

    I don't know of a better solution for that problem than implementing an optimistic locking scheme (which isn't 'locking', after all). That's good enough for most web-based applications and requires much less work on the part of the programmer than a pessimistic locking scheme (not to mention scalabity problems with that latter approach). If someone knows of a better way, I'd like to stand corrected.

    Regards,
    Stefan
  12. Hi Stefan!

    Thank you for your input. I guess there is no other way to implement it. The reason I was wondering about it, is that I would like to have Hibernate behind the DAO, which already offers optimistic locking. But using a DAO I can't use it because I don't work directly with the Hibernate objects. So that's probably the price for decoupling.

    Thanks again,
    Jonas