ServiceWorker: Make claim() uses living matching registrations instead of fetching from DB.

ServiceWorker: Make claim() uses living matching registrations instead of fetching from DB.

Registration can leverage ServiceWorkerProviderHost's MatchRegistration()
method to check whether it is the right registration to claim that client.
So the claim() processing in browser process could be implemented without
hitting the DB to achieve better performance.

BUG=454250
TEST=http/tests/serviceworker/claim*

Committed: https://crrev.com/044a496427d1062450fa29148e16bb9994bd81de
Cr-Commit-Position: refs/heads/master@{#322123}

[xiang, 2015-03-18 05:48:45]

xiang.long@intel.com changed reviewers:
+ falken@chromium.org, michaeln@chromium.org

[xiang, 2015-03-18 05:49:00]

PTAL, thanks.

[michaeln, 2015-03-20 19:25:21]

lgtm!

https://codereview.chromium.org/1013423002/diff/20001/content/browser/service...
File content/browser/service_worker/service_worker_version.cc (right):

https://codereview.chromium.org/1013423002/diff/20001/content/browser/service...
content/browser/service_worker/service_worker_version.cc:1414: return;
this return statement is not needed

[falken, 2015-03-23 00:38:57]

lgtm 2

https://codereview.chromium.org/1013423002/diff/20001/content/browser/service...
File content/browser/service_worker/service_worker_version.cc (right):

https://codereview.chromium.org/1013423002/diff/20001/content/browser/service...
content/browser/service_worker/service_worker_version.cc:1403:
context_->GetLiveRegistration(registration_id_)) {
(unrelated to this patch) I think there might be an existing bug here... does
anything guarantee the registration is live here? We had a similar bug in
crbug.com/465254 that was fixed by ensuring the live registration for starting
SWVersions, but not for running ones.

[michaeln, 2015-03-23 20:02:26]

https://codereview.chromium.org/1013423002/diff/20001/content/browser/service...
File content/browser/service_worker/service_worker_version.cc (right):

https://codereview.chromium.org/1013423002/diff/20001/content/browser/service...
content/browser/service_worker/service_worker_version.cc:1403:
context_->GetLiveRegistration(registration_id_)) {
On 2015/03/23 00:38:57, falken wrote:
> (unrelated to this patch) I think there might be an existing bug here... does
> anything guarantee the registration is live here? We had a similar bug in
> crbug.com/465254 that was fixed by ensuring the live registration for starting
> SWVersions, but not for running ones.

Good question. I think the answer is 'yes', hiroki's patch kept a reference
alive long enough for the a RegistrationHandle to be established on behalf of
the running worker script. See GetRegistrationObjectInfoAndVersionAttributes and
 GetOrCreateRegistrationHandle.

[xiang, 2015-03-24 07:32:51]

Thanks for the review.

https://codereview.chromium.org/1013423002/diff/20001/content/browser/service...
File content/browser/service_worker/service_worker_version.cc (right):

https://codereview.chromium.org/1013423002/diff/20001/content/browser/service...
content/browser/service_worker/service_worker_version.cc:1403:
context_->GetLiveRegistration(registration_id_)) {
On 2015/03/23 20:02:26, michaeln wrote:
> On 2015/03/23 00:38:57, falken wrote:
> > (unrelated to this patch) I think there might be an existing bug here...
does
> > anything guarantee the registration is live here? We had a similar bug in
> > crbug.com/465254 that was fixed by ensuring the live registration for
starting
> > SWVersions, but not for running ones.
> 
> Good question. I think the answer is 'yes', hiroki's patch kept a reference
> alive long enough for the a RegistrationHandle to be established on behalf of
> the running worker script. See GetRegistrationObjectInfoAndVersionAttributes
and
>  GetOrCreateRegistrationHandle.

Thanks for the clarification, yes, the RegistrationHandle will keep the
registration alive after worker starts.

https://codereview.chromium.org/1013423002/diff/20001/content/browser/service...
content/browser/service_worker/service_worker_version.cc:1414: return;
On 2015/03/20 19:25:21, michaeln wrote:
> this return statement is not needed

Done.

[xiang, 2015-03-24 07:33:14]

The CQ bit was checked by xiang.long@intel.com

[xiang, 2015-03-24 07:33:14]

The patchset sent to the CQ was uploaded after l-g-t-m from falken@chromium.org,
michaeln@chromium.org
Link to the patchset: https://codereview.chromium.org/1013423002/#ps40001
(title: "for #3")

[commit-bot: I haz the power, 2015-03-24 07:33:27]

CQ is trying da patch. Follow status at
 https://chromium-cq-status.appspot.com/patch-status/1013423002/40001

[commit-bot: I haz the power, 2015-03-24 09:25:44]

The CQ bit was unchecked by commit-bot@chromium.org

[commit-bot: I haz the power, 2015-03-24 09:25:45]

Try jobs failed on following builders:
  linux_chromium_rel_ng on tryserver.chromium.linux (JOB_FAILED,
http://build.chromium.org/p/tryserver.chromium.linux/builders/linux_chromium_...)

[xiang, 2015-03-25 06:21:45]

The CQ bit was checked by xiang.long@intel.com

[commit-bot: I haz the power, 2015-03-25 06:22:12]

CQ is trying da patch. Follow status at
 https://chromium-cq-status.appspot.com/patch-status/1013423002/40001

[commit-bot: I haz the power, 2015-03-25 06:38:09]

Committed patchset #3 (id:40001)

[commit-bot: I haz the power, 2015-03-25 06:39:07]

Patchset 3 (id:??) landed as
https://crrev.com/044a496427d1062450fa29148e16bb9994bd81de
Cr-Commit-Position: refs/heads/master@{#322123}