CTDB API

[Alexander Bokovoy]

Tridge,

Andrew Tridgell пишет:
> Aleksey,
> 
>> I guess, combining the calls in one function is not very good idea.
>>  We'll have to implement big switch for multiplexing by the call
>> id. And what benefits shall we gain from single ctdb_call function?
>> 
> 
> We gain simplicity :-)
> 
> Also, I realised that a call like CTDB_REQ_FETCH, while being very 
> useful in a demo or in a test suite, isn't actually a good idea for 
> any of our real databases.
> 
> A CTDB_REQ_FETCH call implies that the caller wants to look at the 
> record. Why does it want to do that? To make a decision about the 
> record perhaps, such as if a open should be allowed? In that case it 
> would be much more efficient to make the decision on the DMASTER and 
> to just send the decision (an integer) to the caller, rather than 
> sending the whole record.
Exactly.

> 
> So if CTDB_REQ_FETCH doesn't actually make sense as a specialised
> call for Samba, then what specialised calls do make sense? Not any
> that I can think of :-)
> 
> So I'm now leaning towards just having the general CTDB_CALL, and
> each database instance that uses ctdb will end up with quite
> different calls that it actually implements.
> 
> I know this is a bit different to what I proposed in version 0.2 of 
> the CTDB proposal. That's what happens when you go to actually 
> implement something - you start to think about the problem a lot more
>  carefully :)
> 
> btw, in the little example I posted, I use TDB_DATA for all the data 
> blobs in struct ctdb_call. That wasn't supposed to imply that these 
> would be used only for tdb-style record contents and keys. Only the 
> 'key', 'record_data' and 'new_data' fields contain things that always
>  directly relate to the tdb. The others may well contain data 
> structures, status codes etc.
> 
> A good example is the notion I called 'conditional append' in the 
> proposal. When I started looking at implementing this I realised that
>  the conditional append notion by itself wasn't sufficient, as we
> need to trigger events on the caller that depend on data in the
> record on the DMASTER. For example, there may be delayed opens,
> delayed locks, oplocks etc that need to trigger when records update.
> The data needed to make those calls is stored in the tdb record on
> the DMASTER, but it only makes sense to actually trigger them on the
> caller. Solution? The 'reply_data' field will need to contain a
> structure which tells the caller what was done on the DMASTER, so it
> can trigger the appropriate events.
Yes. This is what we found out as well. Note our discussion on how to
attach triggers on DMASTER to the sub-records so that they will be
called when something happens and issue calls back to a caller.

In your approach you suggest just returning that info back out of the
call directly. We thought that delayed opens/locks/etc might be better
handled at the DMASTER side -- after all, when something comes to
DMASTER with, say, open to already opened record, it might be easier to
notify those who left their triggers for the same record before. Those
triggers might be something of (caller, caller-supplied-id) pair which
just serves that caller-supplied-id back once something like that has
happened. In this case behaviour is left to the caller, DMASTER will
have no knowledge of application-specific reaction other than notifying
the caller back of the event.

> So this is getting more and more RPC like all the time. That isn't a 
> problem, it just means we need the more general CTDB_CALL approach
> and the specific calls won't be sufficient.
Yes, that's OK.

-- 
/ Alexander