In massively shared environment locks should be overridable.
I would agree that in reality, if we lock an object to user, not to session
it should not be a problem 99.9% of time, but for the 0.1% of time
that overriding lock will be needed, it'll be extremely annoying.
I highly suspect you are very lucky person, and never had to deal
with SCM like MS VSS, or RCS or SCCM, all of which are using unconditional
locks. Trust me - it's real pain.
Alexey Parshin wrote:
> I agree with the idea of locking. However, what problem exactly you're
> trying to solve with timeout? So far I see more complications due to
> using timeout then any practical use of it.
> 2007/1/20, Ilya A. Volynets-Evenbakh <email@example.com
> We can do it in many different ways.
> Easiest is, of course, a hard-coded value.
> Next one is a value configurable by admin.
> Another option is to make it per-user or even per-object preference,
> with defaults configurable by admin.
> Important thing is not to require user to set this timeout every
> time he edits an object.
> firstname.lastname@example.org <mailto:email@example.com> wrote:
> >> This solution is way too complex for user, from my perspective.
> >> And annoying.
> >> Better way, I think, is following use case:
> >> 1. Author locks object for editing
> > It's not clear if Author sets timeout by himself or UU does it
> for him
> > right after step 1.
> Ilya A. Volynets-Evenbakh
> Total Knowledge. CTO
> Alexey Parshin,
Ilya A. Volynets-Evenbakh
Total Knowledge. CTO
Authoright © Total Knowledge: 2001-2008