Data Transfer Object // Webservices


XML & Web services: Data Transfer Object // Webservices

  1. Data Transfer Object // Webservices (3 messages)

    Hi there,

    maybe someone can give me an opinion on this:

    I'm using WebServices to transfer data in form of a "Data Transfer Object" between a .NET client and JBoss.

    How can I make sure that the data doesn't get stale, when multiple clients access the same data at the same time?

    I've read some stuff about the "versioning" mechanism, where a version number is saved along with the dto, that is being compared against the version-number stored on the server when a client tries to update data. If the comparison fails (that means another client has already done an update) the update will not take place.

    Is there any better solution to this problem under these circumstances (.Net / J2EE / WebServices) ? Any best practices ??

    thanks in advance

    Threaded Messages (3)

  2. But it's unclear wether you are asking about versioned data (such is client asking to calculate hypothetical value of a quote using old price list that changed since then), or about optimistic locking (client accidentally overriding other changes in price list with his changes)
  3. Patterns[ Go to top ]

    I'm just not too sure what can be implemented at all ... there are loads of locking strategies out there (as used in distributed systems / databases), but given the circumstances that I'm dealing with stateless WebServices and a J2EE and .NET environment (which I'm more or less a newbee to), I'm just unsure what can be done and what not...

    The examples I've come across are about using version numbers or timestamps to prevent (to some kind of degree) that stale data overwrites new data.
  4. Stale data is a fact of life on the web. The only perfect way to avoid stale data is for the server to broadcast updates to all clients, which is incredibly hard to implement on the web (given the difficulty of determine client addresses).

    Most developers address this issue some combination of locking and optimistic concurrency:

    1) Locking: User X checks out record Y, so no one else can change it until User X saves his updates. Usually there is some timeout in case user X never saves anything.

    2) Optimistic Concurrency: User X check out record Y, with a "Last Updated" timestamp of Z. When the user saves his data, if the last update timestamp for record Y is still timestamp Z, everything goes OK. If not, the user gets an error message, and has to merge his updates with the latest values for record Y on the server.