You are viewing a plain text version of this content. The canonical link for it is here.
Posted to derby-dev@db.apache.org by V Narayanan <V....@Sun.COM> on 2007/09/21 16:27:47 UTC
DaemonFactory vs Threads in derby
Hi,
I am working on the LogShipper design for the Replication work. During this
course of that work I am at a place where I need to design a seperate thread
that ships log chunks from the master to the slave. I initially decided on
designing this by using the derby DaemonFactory. But I realize that
there will
be a ShippingDaemon to which only one thread that ships the log records
would
be registered.
I am not sure if this adds to the shipper being more efficient? Would a
thread
be a more efficient option here? would using the DaemonFactory have a
advantage
over using a thread?
Narayanan
Re: DaemonFactory vs Threads in derby
Posted by V Narayanan <V....@Sun.COM>.
Dag H. Wanvik wrote:
> V Narayanan <V....@Sun.COM> writes:
>
>
>> Hi,
>>
>>
>> I am working on the LogShipper design for the Replication work. During this
>>
>> course of that work I am at a place where I need to design a seperate thread
>>
>
> Not sure if it's appropriate in this case, but you may want to look at
> the query cancelling (CancelQueryTask), which builds on a TimerTask.
>
> Dag
>
Thank you for this info. I will take a look at the CancelQueryTask.
Narayanan
Re: DaemonFactory vs Threads in derby
Posted by "Dag H. Wanvik" <Da...@Sun.COM>.
V Narayanan <V....@Sun.COM> writes:
> Hi,
>
>
> I am working on the LogShipper design for the Replication work. During this
>
> course of that work I am at a place where I need to design a seperate thread
Not sure if it's appropriate in this case, but you may want to look at
the query cancelling (CancelQueryTask), which builds on a TimerTask.
Dag