hivemind-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Aleksej <>
Subject Re: Order of discarding of threaded services when there is dependency beetwin them
Date Tue, 24 Jan 2006 12:47:22 GMT
Knut Wannheden wrote:
>>  Well, transaction service has such methods, problem is that it uses
>> connection provided by
>>  other service, which is bound to the same thread and which actually is
>> responsible for
>>  closing that connection. It is possible that connection will be closed
>> before rollback or commit.
>>  Maybe it is possible to inform Hivemind that one service depends on other
>> and that service with
>>  dependency from other must be discarded first? Or maybe Hivemind makes it
>> automatically,
>>  analizing services dependencies?
> Assuming that the connection service closes the connection in the
> threadDidDiscardService() method I don't see how the connection could
> be closed before the commit or rollback in the transaction service has
> executed as your thread probably doesn't clean up after itself until
> after commit (or rollback). Am I missing something?
> --knut
Sorry, I forgot to say that I don't want to call commit/rollback 
explicitly from code, but instead I want
to do it in the threadDidDiscardService() method of transaction service. 
This way I got one transaction
bound to thread. My code can only mark this transaction as succeed ( by 
default transaction is marked as failed ). During thread discard ( 
threadDidDiscardService() method ) transaction service
looks for that flag and if it was set then commit, else rollback. So I 
got 2 services bounded to the same thread and first must be discarded 
AFTER the second. If Hivemind respects dependencies of constructed 
services then everything is OK, but what if two services has references 
on each other ( not
my case but anyway ), in which order Hivemind will discard them?

View raw message