You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@jackrabbit.apache.org by "angela (JIRA)" <ji...@apache.org> on 2005/09/27 15:32:01 UTC
[jira] Created: (JCR-226) Lock.refresh(): throws if lock is alive
Lock.refresh(): throws if lock is alive
---------------------------------------
Key: JCR-226
URL: http://issues.apache.org/jira/browse/JCR-226
Project: Jackrabbit
Type: Bug
Components: locks
Reporter: angela
The spec says:
Lock.refresh():
If this lock's time-to-live is governed by a timer, this method resets that timer so that the lock does not timeout and expire. If this lock's time-to-live is not governed by a timer, then this method has no effect.A LockException is thrown if this Session does not hold the correct lock token for this lock.A RepositoryException is thrown if another error occurs.
The jackrabbit impl does:
/**
* {@inheritDoc}
*/
public void refresh() throws LockException, RepositoryException {
if (isLive()) {
throw new LockException("Lock still alive.");
}
[...]
}
Isn't this a leftover from a very old version of the spec?
There was ones a misunderstanding about the refresh (bringing locks back to live) that has been discussed (mail by david to g. clemm, tobi, peeter and myself, 25.4.2005). as far is i know everybody agreed that this does not make sense and the spec has been adjusted accordingly.
The usage of the refresh is to prevent the lock from being timeouted. That was the original meaning of the refresh, when i suggested it for the JCR locking. If the lock is still alive and there is no timeout to reset, then the method should simply not do anything.
am i missing something?
regards
angela
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
[jira] Assigned: (JCR-226) Lock.refresh(): throws if lock is alive
Posted by "angela (JIRA)" <ji...@apache.org>.
[ http://issues.apache.org/jira/browse/JCR-226?page=all ]
angela reassigned JCR-226:
--------------------------
Assign To: angela
> Lock.refresh(): throws if lock is alive
> ---------------------------------------
>
> Key: JCR-226
> URL: http://issues.apache.org/jira/browse/JCR-226
> Project: Jackrabbit
> Type: Bug
> Components: locks
> Reporter: angela
> Assignee: angela
> Fix For: 1.0
>
> The spec says:
> Lock.refresh():
> If this lock's time-to-live is governed by a timer, this method resets that timer so that the lock does not timeout and expire. If this lock's time-to-live is not governed by a timer, then this method has no effect.A LockException is thrown if this Session does not hold the correct lock token for this lock.A RepositoryException is thrown if another error occurs.
> The jackrabbit impl does:
> /**
> * {@inheritDoc}
> */
> public void refresh() throws LockException, RepositoryException {
> if (isLive()) {
> throw new LockException("Lock still alive.");
> }
> [...]
> }
> Isn't this a leftover from a very old version of the spec?
> There was ones a misunderstanding about the refresh (bringing locks back to live) that has been discussed (mail by david to g. clemm, tobi, peeter and myself, 25.4.2005). as far is i know everybody agreed that this does not make sense and the spec has been adjusted accordingly.
> The usage of the refresh is to prevent the lock from being timeouted. That was the original meaning of the refresh, when i suggested it for the JCR locking. If the lock is still alive and there is no timeout to reset, then the method should simply not do anything.
> am i missing something?
> regards
> angela
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
[jira] Resolved: (JCR-226) Lock.refresh(): throws if lock is alive
Posted by "angela (JIRA)" <ji...@apache.org>.
[ http://issues.apache.org/jira/browse/JCR-226?page=all ]
angela resolved JCR-226:
------------------------
Resolution: Fixed
fixed rev. 344124
> Lock.refresh(): throws if lock is alive
> ---------------------------------------
>
> Key: JCR-226
> URL: http://issues.apache.org/jira/browse/JCR-226
> Project: Jackrabbit
> Type: Bug
> Components: locks
> Reporter: angela
> Assignee: angela
> Fix For: 1.0
>
> The spec says:
> Lock.refresh():
> If this lock's time-to-live is governed by a timer, this method resets that timer so that the lock does not timeout and expire. If this lock's time-to-live is not governed by a timer, then this method has no effect.A LockException is thrown if this Session does not hold the correct lock token for this lock.A RepositoryException is thrown if another error occurs.
> The jackrabbit impl does:
> /**
> * {@inheritDoc}
> */
> public void refresh() throws LockException, RepositoryException {
> if (isLive()) {
> throw new LockException("Lock still alive.");
> }
> [...]
> }
> Isn't this a leftover from a very old version of the spec?
> There was ones a misunderstanding about the refresh (bringing locks back to live) that has been discussed (mail by david to g. clemm, tobi, peeter and myself, 25.4.2005). as far is i know everybody agreed that this does not make sense and the spec has been adjusted accordingly.
> The usage of the refresh is to prevent the lock from being timeouted. That was the original meaning of the refresh, when i suggested it for the JCR locking. If the lock is still alive and there is no timeout to reset, then the method should simply not do anything.
> am i missing something?
> regards
> angela
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
[jira] Updated: (JCR-226) Lock.refresh(): throws if lock is alive
Posted by "Jukka Zitting (JIRA)" <ji...@apache.org>.
[ http://issues.apache.org/jira/browse/JCR-226?page=all ]
Jukka Zitting updated JCR-226:
------------------------------
Fix Version: 1.0
> Lock.refresh(): throws if lock is alive
> ---------------------------------------
>
> Key: JCR-226
> URL: http://issues.apache.org/jira/browse/JCR-226
> Project: Jackrabbit
> Type: Bug
> Components: locks
> Reporter: angela
> Fix For: 1.0
>
> The spec says:
> Lock.refresh():
> If this lock's time-to-live is governed by a timer, this method resets that timer so that the lock does not timeout and expire. If this lock's time-to-live is not governed by a timer, then this method has no effect.A LockException is thrown if this Session does not hold the correct lock token for this lock.A RepositoryException is thrown if another error occurs.
> The jackrabbit impl does:
> /**
> * {@inheritDoc}
> */
> public void refresh() throws LockException, RepositoryException {
> if (isLive()) {
> throw new LockException("Lock still alive.");
> }
> [...]
> }
> Isn't this a leftover from a very old version of the spec?
> There was ones a misunderstanding about the refresh (bringing locks back to live) that has been discussed (mail by david to g. clemm, tobi, peeter and myself, 25.4.2005). as far is i know everybody agreed that this does not make sense and the spec has been adjusted accordingly.
> The usage of the refresh is to prevent the lock from being timeouted. That was the original meaning of the refresh, when i suggested it for the JCR locking. If the lock is still alive and there is no timeout to reset, then the method should simply not do anything.
> am i missing something?
> regards
> angela
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira