Bug 745876 (EDG-77)

Summary:	support optimistic locking with ETags and If-Match in rest server
Product:	[JBoss] JBoss Data Grid 5	Reporter:	Michal Linhard <mlinhard>
Component:	Infinispan	Assignee:	Default User <jbpapp-maint>
Status:	CLOSED NEXTRELEASE	QA Contact:
Severity:	high	Docs Contact:
Priority:	high
Version:	EAP 5.1.0 EDG TP	CC:	mlinhard, nobody, trustin
Target Milestone:	---
Target Release:	EAP 5.1.0 EDG TP
Hardware:	Unspecified
OS:	Unspecified
URL:	http://jira.jboss.org/jira/browse/EDG-77
Whiteboard:
Fixed In Version:		Doc Type:	Bug Fix
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2011-09-16 09:25:59 UTC	Type:	Bug
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:

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