From: John B. <bel...@cs...> - 2001-04-24 16:26:29
|
Hmm, I was thinking some more about this. My idea wasn't going to work as stated (your example showed that). But there is a problem with the first proposal as well: 1. attach 1 writes guid 2. attach 1 reads lease <= Assuming database is not leased, other case not important here 2. attach 1 writes lease 3. attach 1 read guid and gains access to db 4. -- time for attach 1 to renew lease -- 5. attach 2 writes guid 6. attcah 2 begins reading lease 7. attach 1 begins writing lease 8. attach 2 finishes reading and now has corrupted lease Careful design of the lease ODS may make this a non-issue, but I think a better way to fix it may be to write the lease info twice, like: <lease, lease>. When reading the lease, make sure both copies are the same, otherwise re-read. The big concern remains the client side caching. If there is a way to disable it for this part of the db access, then this may just work. There may also be some issues with what happens when the lease for an attach expires, but the client is not out of the db. -John On Tuesday, April 24, 2001, at 07:02 AM, David Jencks wrote: > Hi, > On 2001.04.24 02:28:58 -0400 John Bellardo wrote: >> A couple of thoughts: >> >> 1. caching effects. In order for this to work the writes can not be >> cached locally before being sent to the server. > > Yes, I wasn't aware of caching, I don't know how it works. If it can't > be > turned off, seems like there would be other problems too. >> >> 2. In the following scenario: >> Attach 1 writes uid, checks & writes lease. >> Attach 2 writes uid >> Attach 1 checks uid. >> Attach 2 checks lease and sees that it has not expired. >> Notice that attach 2 is now out of the running, even though no attach >> call owns the lease. While this may not affect correct functionality >> it >> seems bad that there is a situation where there is lease contention and >> all parties involved don't know it. >> > I think both parties do know it. Attach 1 sees uid2, so it knows there > is > interference. Attach 2 sees the valid lease info, so it knows it can't > attach. How long they should wait before trying again is my question. > >> Here is a similar idea: >> >> 1. read <guid1, lease, guid2> touple. if guid1 == guid2 then the lease >> is valid and respect it. >> 1a. If it is our lease, we're in :) >> 2. If lease is not valid write toupe <myguid, lease, myguid> and goto >> step 1. >> >> This method has the nice effect that if an attach crashes it can >> reconnect (assuming guid are good enough) without waiting for the lease >> to expire. In fact we could maintain a log somewhere with the database >> info and the guid used to connect to it, and attempt some house >> cleaning >> when recovering from a crash. > > I think maybe you left out some details, I don't understand your > proposal. > With mine, it would certainly make sense to read the info before writing > your uid to make sure there isn't a valid lease. I should have put that > in. I'm trying to avoid an interleaving problem. I don't understand > how > your proposal prevents this, that's why I think you left out some steps > you > have in mind. > > attach 1 reads <guid1, lease, guid2>. lease has expired. > > attach 2 reads <guid1, lease, guid2>. lease has expired. > > attach 1 writes <guid1, lease, guid2>. to try to get its lease. > > attach 1 reads <guid1, lease, guid2>, sees its new lease, just as it > wrote > it. It thinks it has the db. > attach 2 writes <guid1, lease, guid2>. to try to get its lease. > > attach 2 reads <guid1, lease, guid2>, sees its new lease, just as it > wrote > it. It thinks it has the db. > > > Now both 1 and 2 think they have the lease. > > In addition i'm not quite sure what "if an attach crashes it can > reconnect" > means. If it crashes in what sense can it be the same thing on restart? > I'd prefer to set the lease times short and make no assumptions about > identity. > > > Thanks > David Jencks > >> >> I still think caching will be the biggest problem. I don't know NFS >> (but I assume it does not suffer from the caching problem), but it >> would >> be great if this locking method also allowed us to run multiple servers >> on a single local system. >> >> -John >> >> On Monday, April 23, 2001, at 05:22 PM, David Jencks wrote: >> >>> Hi, >>> >>> I know the arguments about why this is a bad idea, and I found holes >>> easily >>> enough in all the previous schemes I've cooked up for this but maybe >>> this >>> one will work. >>> >>> 2 problems: >>> 1. 2 or more servers might attach at more or less the same time ==> >>> disaster. >>> >>> 2. If the server that is attached crashed, how is db freed for someone >>> else? >>> >>> >>> This idea uses the concept of leasing resources borrowed from JINI. >>> >>> We need 2 data locations in the database: >>> --global uid >>> >>> --lease info (who holds the lease, when it expires) >>> >>> >>> When a server needs to attach a db, it does this; >>> >>> 1. Write to the guid, remembering the value (something like ip address >> + >>> timestamp?) >>> >>> 2. Read the lease info. >>> >>> 3. If the db is available (lease expired), write new lease info. If >>> not, >>> stop. >>> >>> 4. Read the guid. If it matches, no one else has tried to attach >>> while >> >>> we >>> were working. If it doesn't, we didn't get the lease and must try >> again >>> later. >>> >>> So if another server starts this process before step 4 is started, the >>> GUID >>> will be wrong and we know interference happened. If the second server >>> gets >>> in before step 3, it will presumably get the db. If it gets in after >>> step >>> 3, it won't, there is current leasing info showing the db is in use: >>> noone >>> will get the db, someone will have to try again later. >>> >>> Also the winning server has to be sure to renew it's lease before its >>> up. >>> I think in JINI leases are often for 5-10 minutes and renewed maybe >>> halfway >>> through to account for network latency etc. >>> >>> This would be easier with JINI to provide the leasing service but I >>> think >>> this will work. >>> >>> Anyone see any holes in it? >>> >>> Thanks >>> David Jencks >>> >>> >>> >>> On 2001.04.23 22:10:57 -0400 Mark O'Donohue wrote: >>>> >>>> Hi >>>> >>>> I know this is some sort of feature, but Im just wondering if it's >>>> useby >>>> date isn't up. >>>> >>>> When opening a database, on linux/unix the open goes to a fair amount >>>> of >>>> trouble to check where the file is, if it is on a nfs shared drive >> then >>>> it assumes that it needs to make a network connection to an FB/IB >>>> server >>>> on the actual host that exports the nfs share. >>>> >>>> I can see that you don't programs from different machines opening the >>>> database, since locking and signals are restricted to one machime, >> but >>>> it's a pain in the neck when you actually want to run on the current >>>> machine and the nfs drive is just that a shared drive your using. >>>> >>>> So is there a switch somewhere to disable this? >>>> >>>> For example I can't build even the boot build on sourceforge because >>>> everything is an nfs drive of some sort, and gbak keeps actually >>>> wanting >>>> to contact the machine fserv. >>>> >>>> >>>> Cheers >>>> >>>> Mark >>>> >>>> >>>> skywalker@usw-pr-shell1:~/work/interbase$ >>>> source/interbase/bin/gbak -g >>>> -c misc/metadata.gbak fred.gdb >>>> gbak: ERROR: Unable to complete network request to host "fserve". >>>> gbak: ERROR: Failed to establish a connection. >>>> gbak: ERROR: Connection refused >>>> gbak: ERROR: failed to create database fred.gdb >>>> gbak: Exiting before completion due to errors >>>> >>>> >>>> And my home directory is on: >>>> >>>> skywalker@usw-pr-shell1:~/work/interbase$ df . >>>> Filesystem 1k-blocks Used Available Use% Mounted on >>>> fserve:/home/users 8327592 7063400 1180256 86% /home/users >>>> >>>> >>>> -- >>>> Your database needs YOU! >>>> http://firebird.sourceforge.net >>>> >>>> >>>> _______________________________________________ >>>> Firebird-devel mailing list >>>> Fir...@li... >>>> http://lists.sourceforge.net/lists/listinfo/firebird-devel >>>> >>> >>> >>> _______________________________________________ >>> Firebird-devel mailing list >>> Fir...@li... >>> http://lists.sourceforge.net/lists/listinfo/firebird-devel >>> >> >> _______________________________________________ >> Firebird-devel mailing list >> Fir...@li... >> http://lists.sourceforge.net/lists/listinfo/firebird-devel >> > > > _______________________________________________ > Firebird-devel mailing list > Fir...@li... > http://lists.sourceforge.net/lists/listinfo/firebird-devel > |