[Kroupware] Questions about Shared Resources & Concurrent Access

Bernhard Reiter bernhard at intevation.de
Tue May 20 17:07:20 CEST 2003


On Monday 19 May 2003 22:10, Diego Rivera wrote:
> On Mon, 2003-05-19 at 14:45, Martin Konold wrote:
> > Am Montag, 19. Mai 2003 18:25 schrieb Diego Rivera:

> > > Well...here's the thing:  room1 might not necessarily have a person
> > > assigned to confirm bookings to it.
> > >
> > > Assume two users: user A and user B trying to get a 1 hour, 1:00pm
> > > meeting with resource X.
> > >
> > > A and B both try to get the appointment at the same time, read the
> > > existing appointments, realize 1:00pm is open, and book the
> > > appointments.  Thus, 1:00pm is double-booked.  In the scenario I
> > > describe, the correct behavior would be that one of them gets bounced
> > > because the other beats them in the race.
> > >
> > > However, this gets complicated to do (using anything short of a
> > > dedicated calendaring server product) using file-transfer mechanisms.
> > > Mutex locking with file transfers run the risk of clients holding locks
> > > through crashes, which is NOT correct behavior.
> >
> > Well, basically the user trying to book a ressource has to wait for the
> > confirmation. The kde kolab client only sends a single confirmation on a
> > first come first serve race in case you chose the automatic mode.
>
> That's exactly my point : while the Kroupware client might have
> mechanisms for doing this - what IF they're not using Kroupware?  Say -
> Outlook over FTP?  That will be a common scenario and I don't see any
> true way to keep this from happening.

To add the answers of Bo and Martin let me note that

if room1 does not have a person assigned to it, it has a Kolab client
running on the account in automatic mode.

the technical reason why one would arrive earlier than the other
without conflicts is the mail system. One mail will arrive earlier.

The client A and B have do not matter.
They just get confirmations or declines.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 3052 bytes
Desc: signature
Url : http://mail.kde.org/pipermail/kroupware/attachments/20030520/698c64bf/smime-0001.bin


More information about the Kroupware mailing list