Announcement Announcement Module
Collapse
No announcement yet.
how can I check conflicts on updating? Page Title Module
Move Remove Collapse
X
Conversation Detail Module
Collapse
  • Filter
  • Time
  • Show
Clear All
new posts

  • how can I check conflicts on updating?

    how can I check conflicts on updating?

    in a web application,

    how to avoid two people to update a record on same time?

    for example:

    there are two people A and B

    A and B read recorder rec_original.

    A updated recorder to rec_a

    B doesn't know A has updated .


    he try to update rec_original to rec_b. NOW it's a conflict How to check that was occured .
    ( as CVS)

    I use hibernate and jdbc.

  • #2
    This is a classic locking problem. Please refer to references on pessimistic and optimistic locking. Pessimistic locking locks resources in the database (e.g. with a SELECT...FOR UPDATE), while optimistic locking using version numbering or the like to resolve conflicts in the application.

    Databases (and hence JDBC) support pessimistic locking. You can write optimistic locking code yourself or any good ORM solution will provide useful support.

    Comment


    • #3
      Re: how can I check conflicts on updating?

      Originally posted by creatxr
      I use hibernate and jdbc.
      Hibernate has great support for optimistic (versioning and timestamp) and pessimisting locking (through jdbc). Check out the reference documentation:http://www.hibernate.org/hib_docs/v3...nsactions.html

      Comment


      • #4
        Re: how can I check conflicts on updating?

        Originally posted by costin
        versioning and timestamp
        I know the solution of versioning --- it seems to add a version field to table. is it correct?


        how about timestamp?

        Comment


        • #5
          Re: how can I check conflicts on updating?

          Originally posted by creatxr
          Originally posted by costin
          versioning and timestamp
          I know the solution of versioning --- it seems to add a version field to table. is it correct?


          how about timestamp?
          All you need it's written down in the reference documentation. In both cases you need an additional column.

          Comment


          • #6
            The most easiest way, I know about is by referencing old values and using them within the update clause. It is like the old lazy locking sheme goes:

            Code:
            1. Fetch objectA
            2. Remember objectA as oldObjectA
            3. Do lots of calculation
            4. Start transaction
            5. Compare current status of objectA in the database and compare it with the old status of objectA
            6. write changed status of objectA
            7. end transaction
            Comparing and setting can be done within the same SQL update clause. It isn't that neat but often enough it is a nice idea for simple workflow situations and legacy tables. (beside the old multi-processor assembler stuff).

            @creatxr

            Check out this resource to give a nice introduction into locking versioning and stuff: http://developer.apple.com/documenta...Topics.2a.html

            I know the solution of versioning --- it seems to add a version field to table. is it correct? how about timestamp?
            Check out the hibernate reference manual (or Hibernate in Action if you have) and check out the version and timestamp tag. There is a short but complete discussion about when to use which and why versioning is preferable.

            The related Hibernate manual parts can be found at: http://www.hibernate.org/hib_docs/v3...ration-version


            Cheers,

            Martin (Kersten)

            Comment

            Working...
            X