Re: Order of discarding of threaded services when there is dependency beetwin them

[Aleksej]

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?