[bind10-dev] revised/refactored data source design proposal

[Michal 'vorner' Vaner]

Hello

On Fri, Jun 03, 2011 at 11:36:00AM -0700, JINMEI Tatuya / 神明達哉 wrote:
> BTW, are you saying this is what we decided at the last f2f?  If so,
> maybe I really didn't understand the seeming consensus correctly (I'm
> not necessarily opposing to the idea itself, although it seems more
> ambitious and will have more technical challenges).

Well, AFAIK we agreed on that something in this direction would be a good way to
solve many problems. So, while we didn't yet commited to writing it that way, I
kind of expected this is the way we're considering right now. And we didn't
specify full details, of course, and if there's update only through the DB or
not is definitely a detail, but that's the easiest way I personally see. I might
have misunderstood.

> I don't oppose to efforts of ensuring full consistency.  If this is
> something users really care about but only BIND 10 can provide, that
> would be very nice indeed.  My only point is that we should be careful
> not to do over-engineering for something that is not needed by actual
> users and that only satisfies engineers' ego.

My point here was it would be quite easy to leave the door for it open if we
ever decide in future we'd like to do it. I didn't say it's necessary, and I
don't really see a place where it could be a problem in the normal-DNS world. I
have no problem with deciding we don't want that, but I simply noticed it in the
old code and in the new proposal, so I wanted to ask if it really is intended.

> If I remember correctly, SQLite3 doesn't even allow that (MySQL allows
> it with the condition you mentioned), but as I will note below I think
> we can find a way to work this around if it's really needed.

Really? How it can know it moved from one thread to another except by explicitly
asking for the thread ID (and doing so explicitly looks like a stupid way to
introduce restriction on use). But if it really is there, then the pool approach
might be problematic.

> One of my concerns in this case is if we pass a connection state
> holding an open transaction to an application, it will open up a wider
> possibility of starvation due to a bug in the application side.
> Another concern when we use the entire "client" for the transaction,
> it may cause a confusing results such as the application tries to
> start a writable transaction using the same client and blocks due to
> its own read transaction.

Do DBs really distinguish between read transaction and write transaction on the
user side? I never heard of such thing.

> > I don't know, they are probably effective enough in the big DBs,
> > they just start sending you sending row after row and you read them
> > one by one. I can't imagine anything more effective in the DB world,
> > but I'm not expert there at all.
> 
> I'm not sure we're talking about the same thing...is your comment
> about the "another discussion"?  If so, yes, "they just start sending
> you row after row and you read them one by one".  The problem is it
> may take longer time, during which the database is read-locked and
> cannot be updated.

Ah, well, while being unimportant, I believe they don't really do such thing.
They tried to teach us how DBs work inside and insisted on some keeping copies
when rewriting it and something still reads the old state, and not really
locking in most cases (but I have some doubts about how real the stuff they were
telling was, some of the things didn't really make sense).

With regards

-- 
BOFH Excuse #452:
Somebody ran the operating system through a spelling checker.

Michal 'vorner' Vaner
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: not available
URL: <https://lists.isc.org/pipermail/bind10-dev/attachments/20110604/be0e7372/attachment.bin>