You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@hivemind.apache.org by Aleksej <al...@ivs.lt> on 2006/01/24 09:51:54 UTC
Order of discarding of threaded services when there is dependency
beetwin them
Lets say I have 2 threaded services, and one of them is must be created
before other AND discarded after it. One service must wrap other in
time. Idea is to create database connection service
and transaction service. Transaction service is wired with database
connection and at the end of thread it must commit or rollback all
changes. But because there is no order of discard specified, it is
possible, that Hivemind first will discard connection service and then
will try to discard transaction service, which will try to
commit/rollback using already closed connection. Any
ideas/recomendations/tricks how to solve such problem?
---------------------------------------------------------------------
To unsubscribe, e-mail: hivemind-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: hivemind-user-help@jakarta.apache.org
RE: Order of discarding of threaded services when there is dependency beetwin them
Posted by James Carman <ja...@carmanconsulting.com>.
Off the top of my head, I'd have to say that HM would notify the first
service that was constructed (which would probably be the transaction
service) since it registers itself first with the ThreadEventNotifier
service. What sort of application is this? Web-based? Are you using the
servlet filter to cleanup the thread(s)? You may have uncovered something.
I'll have to think on it a bit. I haven't had enough coffee yet this
morning, though! :-)
_____
From: Aleksej [mailto:aleksej@ivs.lt]
Sent: Tuesday, January 24, 2006 7:47 AM
To: hivemind-user@jakarta.apache.org
Subject: Re: Order of discarding of threaded services when there is
dependency beetwin them
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?
Re: Order of discarding of threaded services when there is dependency
beetwin them
Posted by Aleksej <al...@ivs.lt>.
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?
Re: Order of discarding of threaded services when there is dependency beetwin them
Posted by Knut Wannheden <kn...@gmail.com>.
>
> 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
---------------------------------------------------------------------
To unsubscribe, e-mail: hivemind-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: hivemind-user-help@jakarta.apache.org
Re: Order of discarding of threaded services when there is dependency
beetwin them
Posted by Aleksej <al...@ivs.lt>.
Knut Wannheden wrote:
> Aleksej,
>
> On 1/24/06, Aleksej <al...@ivs.lt> wrote:
>
>> Lets say I have 2 threaded services, and one of them is must be created
>> before other AND discarded after it. One service must wrap other in
>> time. Idea is to create database connection service
>> and transaction service. Transaction service is wired with database
>> connection and at the end of thread it must commit or rollback all
>> changes. But because there is no order of discard specified, it is
>> possible, that Hivemind first will discard connection service and then
>> will try to discard transaction service, which will try to
>> commit/rollback using already closed connection. Any
>> ideas/recomendations/tricks how to solve such problem?
>>
>>
>
> Why don't you execute the commit / rollback before the service
> instances are being discarded? Can't your transaction service have
> explicit methods for commit and rollback?
>
> --knut
>
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?
Re: Order of discarding of threaded services when there is dependency beetwin them
Posted by Knut Wannheden <kn...@gmail.com>.
Aleksej,
On 1/24/06, Aleksej <al...@ivs.lt> wrote:
> Lets say I have 2 threaded services, and one of them is must be created
> before other AND discarded after it. One service must wrap other in
> time. Idea is to create database connection service
> and transaction service. Transaction service is wired with database
> connection and at the end of thread it must commit or rollback all
> changes. But because there is no order of discard specified, it is
> possible, that Hivemind first will discard connection service and then
> will try to discard transaction service, which will try to
> commit/rollback using already closed connection. Any
> ideas/recomendations/tricks how to solve such problem?
>
Why don't you execute the commit / rollback before the service
instances are being discarded? Can't your transaction service have
explicit methods for commit and rollback?
--knut
---------------------------------------------------------------------
To unsubscribe, e-mail: hivemind-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: hivemind-user-help@jakarta.apache.org