web services - How to do the equivalent of SELECT .. FRO UPDATE in a SOA architecture? -


The title is probably not clear, so try to explain to me that I'm working on a new project, which is made on the net It has WPF clients, which use WCF web services to access Oracle databases. The problem is not the basic architecture, but rather from what place it is already working.

Currently, applications are written using PowerBuilder and connect directly to the database. In addition, they use the Oracle's SELECT .. FOR UPDATE statements so that concurrency can be managed by locking the record. Since new applications should be present along with the old people, they want to lock the archives in the same way, but new architectures dependent on web services do not make it easy.

At the moment, what we are thinking of doing is making "data server" which will be called by the web services and responsible for accessing the database. The purpose of this server is to maintain the necessary open connection / transaction to maintain record lock in many web service calls. This is necessary because the "selection" and the "update" parts that require SELECT .. UPDATE is required, at least two different web service calls are most likely to be in ("Get the record" and "Post updates").

I have searched the Internet for documentation about this situation, but I can not find much information on this topic. Can this be? Open Record Lock to Meet Many Web Services? properly? Is my attitude fair? Is there any published "best practice" on this subject?

Update: The original title of the question was How to maintain record locking with a service oriented architecture? I changed it after John's suggestion, hopefully it inspires some answers. Usually the SOA has already started the XA transaction so you can take advantage of it and update / selection /

  • MY_TABLE SET state = 'working' UPDATE; ...;
  • SELECT * to MY_TABLE WHERE status = 'Working' ...

    Then you can process the data with the fear of someone else and already The data will be claimed in a different 'state', provided that the service that you write only one in the existing for each table

    Finally, you can complete it with updates ... set. .. State = Where 'Full' is located = 'Work' By the way, this is the same strategy that uses the database adapter for voting.

Comments

Post a Comment