1 Reply Latest reply on Jan 23, 2007 6:59 PM by Gavin King

    concurrent conversations changing same data

    Leo Baschy Novice

      Would like to know what the defined / expected behavior is. Have many real examples, but here is a simplistic one for illustration.

      I want to know what the default behavior is. What is considered "normal". Sure, workarounds are nice to know, but what is the "intended" way?

      User U1 enters online grocery store, starts Seam conversation to order items. Picks last loaf of bread (inventory count from 1 down to 0). No extra conversations, please I want to have a problem here. U1 stays in conversation to look and to order other items.

      Is that bread order now in Seam's memory copy? Is it uncommitted in database? I guess I shouldn't care. I only should care it isn't committed yet, right?

      Let's assume my database is a MySQL or Oracle that someone has installed with default settings. What would that be more commonly, which isolation level? Does it matter or not?

      Other user, U2, enters store now. I assume he still sees that last loaf of bread. Right? U1 hasn't ended conversation, hence hasn't committed yet, right? U2 picks that last loaf of bread too. He checks out, coded to end conversation, causes commit. U2 is happy.

      U1 finally is done and checks out with all items he has ordered. Will there be a conflict of versions at the inventory for bread? I guess I'd need to figure how to Hibernate annotate for version. What exception will be thrown then?

      Are people expected to recognize the probem from the exception and fix it partially, or is the whole transaction a loss then? I assume the whole transaction is gone bye bye, people don't try to fix parts.

      Now what if I don't code a version for the record, and there won't be a version conflict. Will simply both U2 and U1 set the inventory for bread to zero?

      Sure, in a real application I could make separate conversations of each item picked, so the decreased inventory commits, and then if the whole order doesn't get bought then return it.

      The point of this question is what is supposed to happen in Seam in a simply programmed example.

      Knowing what can happen can make the risk less scary, more acceptable.