Hi,I have two threads which will maintain separate connections to samekdb database. One thread will be performing select and insert on thetables whereas another thread will perform delete query in order topurge data at regular interval.It will be helpful if you can answer,1. How does kdb handle concurrent update of same table by multiplethreads?2. Does it provide table locks or any other mechanism to synchronizeaccess to table in order to avoid data corruption?3. Is there any kdb mechanism which can be used to avoid lockingoverhead?Thanks, Nilesh
In the default single threaded mode, kdb+ will not process requests concurrently.
In the multithreaded input mode, i.e. started with a negative port number, updates are currently possible from the timer expiry function .z.ts only, during which queries via ipc are suspended (all run to completion).
thanks
Is there some documentation about the multithreaded mode and thenegative port number related entry somewhere? Thanks a lot.On 3/15/12, Nilesh <nilesh.da> wrote:> Hi,>> I have two threads which will maintain separate connections to same> kdb database. One thread will be performing select and insert on the> tables whereas another thread will perform delete query in order to> purge data at regular interval.>> It will be helpful if you can answer,> 1. How does kdb handle concurrent update of same table by multiple> threads?> 2. Does it provide table locks or any other mechanism to synchronize> access to table in order to avoid data corruption?> 3. Is there any kdb mechanism which can be used to avoid locking> overhead?>> Thanks,> Nilesh>– Sent from my mobile deviceRegards, Arpan-----------------------------------------------------------------------------------------------------------------Reality is merely an illusion, albeit a very persistent one.</nilesh.da>
Charles,Thanks for reply.So as I understand in single threaded kdb+ , all the queries will beserialized by kdb and executed in order even though they were fired bydifferent application threads (with separate connections to kdbdatabase) of same c++ process.Please confirm.Thanks,NileshOn Mar 15, 1:39?pm, Charles Skelton <char…> wrote:> In the default single threaded mode, kdb+ will not process requests> concurrently.>> In the multithreaded input mode, i.e. started with a negative port number,> updates are currently possible from the timer expiry function .z.ts only,> during which queries via ipc are suspended (all run to completion).>> thanks>>>>>>>> On Thu, Mar 15, 2012 at 10:18 AM, Nilesh <nilesh…> wrote:> > Hi,>> > I have two threads which will maintain separate connections to same> > kdb database. One thread will be performing select and insert on the> > tables whereas another thread will perform delete query in order to> > purge data at regular interval.>> > It will be helpful if you can answer,> > 1. ? ? ?How does kdb handle concurrent update of same table by multiple> > threads?> > 2. ? ? ?Does it provide table locks or any other mechanism to synchronize> > access to table in order to avoid data corruption?> > 3. ? ? ?Is there any kdb mechanism which can be used to avoid locking> > overhead?>> > Thanks,> > ?Nilesh>> > –> >
Submitted via Google Groups</nilesh…></char…>
In single threaded mode - only a single query is actively being processed at any time.
For any single tcp connection, queries received on that socket are executed in the order of issue from the remote.
For multiple connections, the order of execution is as they become available from the tcp stack, which is not necessarily the order of issue by different remotes - within any single connection the sequence of issue is retained.
thanks
Thanks a lot.On Mar 16, 5:35?am, Charles Skelton <char…> wrote:> In single threaded mode - only a single query is actively being processed> at any time.>> For any single tcp connection, queries received on that socket are executed> in the order of issue from the remote.>> For multiple connections, the order of execution is as they become> available from the tcp stack, which is not necessarily the order of issue> by different remotes - within any single connection the sequence of issue> is retained.>> thanks>>>>>>>> On Fri, Mar 16, 2012 at 10:16 AM, Nilesh <nilesh…> wrote:>> > Charles,>> > Thanks for reply.>> > So as I understand in single threaded kdb+ , all the queries will be> > serialized by kdb and executed in order even though they were fired by> > different application threads (with separate connections to kdb> > database) of same c++ process.>> > Please confirm.>> > Thanks,> > Nilesh>> > On Mar 15, 1:39 pm, Charles Skelton <char…> wrote:> > > In the default single threaded mode, kdb+ will not process requests> > > concurrently.>> > > In the multithreaded input mode, i.e. started with a negative port> > number,> > > updates are currently possible from the timer expiry function .z.ts only,> > > during which queries via ipc are suspended (all run to completion).>> > > thanks>> > > On Thu, Mar 15, 2012 at 10:18 AM, Nilesh <nilesh…> wrote:> > > > Hi,>> > > > I have two threads which will maintain separate connections to same> > > > kdb database. One thread will be performing select and insert on the> > > > tables whereas another thread will perform delete query in order to> > > > purge data at regular interval.>> > > > It will be helpful if you can answer,> > > > 1. ? ? ?How does kdb handle concurrent update of same table by multiple> > > > threads?> > > > 2. ? ? ?Does it provide table locks or any other mechanism to> > synchronize> > > > access to table in order to avoid data corruption?> > > > 3. ? ? ?Is there any kdb mechanism which can be used to avoid locking> > > > overhead?>> > > > Thanks,> > > > ?Nilesh>> > > > –> > > > You received this message because you are subscribed to the Google> > Groups> > > > “Kdb+ Personal Developers” group.> > > > To post to this group, send email to personal-kdbplus@googlegroups.com> > .> > > > To unsubscribe from this group, send email to> > > > personal-kdbplus+unsubscribe@googlegroups.com.> > > > For more options, visit this group at> > > >http://groups.google.com/group/personal-kdbplus?hl=en.>> > –> >
Submitted via Google Groups</nilesh…></char…></nilesh…></char…>