[
Lists Home |
Date Index |
Thread Index
]
Ok. I see. I don't think REST knows squat about the
locking strategy of the database nor should it. On
the other hand, that looks like what RPC is designed
for and REST isn't. I see your point about the lockfile.
I will watch this thread carefully to see who has
solved this one.
Additionally, one has to deal with the fact that
some relational server systems have waaaay better locking
strategies than others. As we are hearing tales of
servers locking up and dieing (why I mentioned replication),
the recent announcements of pricing wars among relational
server vendors are being welcomed warmly.
The value of any elegant theory approaches zero as
the RGB value of the B singleton approaches 1.
len
From: ari@cogsci.ed.ac.uk [mailto:ari@cogsci.ed.ac.uk]
"Bullard, Claude L (Len)" <clbullar@ingr.com> writes:
> I'm not sure what you are trying to achieve.
User A GETs a resource and edits it. User B GETs a resource and edits
it. User A PUTs the modified resource back. User B PUTs her version of
the modified resource back, unaware of A's edits. A's edits are lost
without anyone noticing. What I want to happen is B to get a 409
"Conflict" or some such.
> REST isn't a good idea for isolating a transaction unless that
> transaction is expressed as a document.
A lockfile is a document. Just not one I would have thought should be
exposed to the user :=)
> 1. REST doesn't remove the requirement for replication, as in,
> a server collapsing under the load of both transactional
> updates and deletes while simultaneously attempting to process
> requests for reports. Create a report server and replicate to it.
> REST is likely good for that.
There are no replication requirement in this project.
> 2. REST thrives as the granularity of a document/dataset; that is, a
> report.
Yes, that's why I want to know more about it :=)
|
