On 03/30/11 18:28, Adriano dos Santos Fernandes wrote: > On 30-03-2011 08:51, Alex Peshkoff wrote: >> Let's leave it for another thread. >> >>> - ITransaction::disconnect - must be added >>> - Few other things (TODO) >>> >>> Cleanup handlers was added to the API, as they are part of public ISC API. >> I'm not sure with them. May be better leave that support only for ISC >> API emulator? >> > I'm not sure, really. > > disconnect looks like a valid operation and I think we must support.
Yes, disconnect is valid operation. It does not make much sense for user - this is a method to help him to leave transaction in limbo state :) Unfortunately this is the only thing that multithread server can do when connection to client is lost in unsuccessfull moment. Therefore - yes, we have to have ITransaction::disconnect(). > About cleanup handles, looks like some day they was needed, so... > The only handler left in our codes is in user_dsql.cpp, it's isc_database_cleanup(). As far as I can see from that code handler is needed when adding thin wrapper, which adds additional services, but lets upper layers work with original handles instead of creating own handles. Therefore such layer has no direct control over (for example) detach from database and needs a handler to cleanup own database related resources. Can't say that I like that approach. >>> As I said, proxies on the engine would be possible, and don't require >>> any sort of addRef/release in our API. But I don't saw yet any concrete >>> design plan on how this will work. >> How can it arrive if we have to waste time with your suggestion not to >> use reference counters in API? >> Proxies make no sense without reference counters, they will not work as >> needed. >> > Like you said, someone may kill an attachment from another connection. > > If we can't inform yvalve about this, and with current way to call > cleanup handler after the object is constructed looks not safe. > > So IMHO, when an attachment dies it must mark it parent proxy as > invalid, and this proxy would die only together with the yvalve object. > Exactly. And only when all it's proxy-children (proxy for transaction is a child of proxy for attachment) are dead. ------------------------------------------------------------------------------ Create and publish websites with WebMatrix Use the most popular FREE web apps or write code yourself; WebMatrix provides all the features you need to develop and publish your website. http://p.sf.net/sfu/ms-webmatrix-sf Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel