On Tue, Oct 11, 2011 at 17:30, Simon Slavin wrote:
>
> On 11 Oct 2011, at 4:01pm, Gal Waldman wrote:
>
> >> If you don't mind inconsistency due to changes not being included in the
> >> same transaction, it may be that doing faster changes but leaving a tiny
On Tue, Oct 11, 2011 at 16:39, Simon Slavin wrote:
>
> On 11 Oct 2011, at 3:19pm, Gal Waldman wrote:
>
> > - Currently we use a single DB and encounter SQLITE_BUSY more times
> than
> > we can afford ( we want to let the monitor handle more probes )
>
> Okay,
mon Slavin wrote:
>
> On 11 Oct 2011, at 12:28pm, Gal Waldman wrote:
>
> > We do encounter locking problems on configuration changes ( currently it
> is
> > a single DB file )
> > For Statistic write operation optimization we collect all data and write
&g
ct 11, 2011 at 12:02, Simon Slavin wrote:
>
> On 11 Oct 2011, at 9:56am, Gal Waldman wrote:
>
> > I am looking for ideas/solutions for Concurrency in my application.
> > I have web-server for user configuration, where configuration changes ->
> > write operation i
Hello,
I am looking for ideas/solutions for Concurrency in my application.
I have web-server for user configuration, where configuration changes ->
write operation is scarce, at the same time I have a single monitor
application which collect information from multiple probes which does lots
of stati
5 matches
Mail list logo
