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