Bug 745876 (EDG-77) - support optimistic locking with ETags and If-Match in rest server
Summary: support optimistic locking with ETags and If-Match in rest server
Keywords:
Status: CLOSED NEXTRELEASE
Alias: EDG-77
Product: JBoss Data Grid 5
Classification: JBoss
Component: Infinispan
Version: EAP 5.1.0 EDG TP
Hardware: Unspecified
OS: Unspecified
high
high
Target Milestone: ---
: EAP 5.1.0 EDG TP
Assignee: Default User
QA Contact:
URL: http://jira.jboss.org/jira/browse/EDG-77
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2011-04-04 16:35 UTC by Michal Linhard
Modified: 2014-03-17 04:02 UTC (History)
3 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2011-09-16 09:25:59 UTC
Type: Bug


Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
Red Hat Issue Tracker EDG-77 0 Major Closed support optimistic locking with ETags and If-Match in rest server 2012-10-17 08:22:48 UTC
Red Hat Issue Tracker ISPN-1084 0 Major Resolved support optimistic locking with ETags and If-Match in rest server 2012-10-17 08:22:48 UTC

Description Michal Linhard 2011-04-04 16:35:06 UTC
project_key: EDG

I don't know whether this is a bug or a feature request (I'm no good at interpreting specifications)
But we have a problem with this one:
http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html#sec14.24

currently it is not possible to do optimistic locking using the ETag feature in the REST server, because the "If-Match" HTTP header is ignored.

We allow to put a value many times with the same "If-Match" header, but according to the spec:
{quote}
"A request intended to update a resource (e.g., a PUT) MAY include an If-Match header field to signal that the request method MUST NOT be applied if the entity corresponding to the If-Match value (a single entity tag) is no longer a representation of that resource. This allows the user to indicate that they do not wish the request to be successful if the resource has been changed without their knowledge. "
{quote}

Comment 1 Trustin Lee 2011-05-04 12:16:47 UTC
I think this is both a bug and a feature request at the same time.

If {{If-Match}}, {{If-None-Match}}, and other related headers are not supported yet, the server must respond with the {{501 Not Implemented}} status.  Therefore, it's a bug in Infinispan's REST implementation if it does not respond correctly.  Implementing optimistic locking is another story, and it should be implemented in Infinispan 5.1 since it's a new feature.

Sounds OK?

Comment 2 Michal Linhard 2011-05-04 12:23:02 UTC
OK so let this jira be about the bug and adding the proper 501 response.

And I'll create a feature request for ISPN 5.1

Comment 3 Michal Linhard 2011-05-04 12:31:24 UTC
Link: Added: This issue relates to ISPN-1084


Comment 4 Trustin Lee 2011-05-11 09:42:27 UTC
Link: Added: This issue is related to ISPN-1098


Comment 5 Tristan Tarrant 2011-09-16 09:25:59 UTC
Release Notes Text: Added: Infinispan 5.1.0.Alpha1 contains the fix for ISPN-1084


Comment 6 Anne-Louise Tangring 2011-10-11 17:06:07 UTC
Release Notes Text: Removed: Infinispan 5.1.0.Alpha1 contains the fix for ISPN-1084 



Note You need to log in before you can comment on or make changes to this bug.