Database Buffered Group Settings

I was wondering, I had read in a posting somewhere on this site about the Buffered Group Settings in FSQL. They are under the advanced tab of the group which needs to be enabled by the end user.

Anyway I had some questions about this. In the manual it says that it is a good thing to enable this because of the lag time in which it takes FSQL to detect a database is down. This part make sence.

But in the next statement it says something about there only be 1 thread per connection. Can you elaborate on this thread comment?

SOme question might be how much data can the thread hold?

If there has been a write to this thread but that data has not yet been dumped over the the database and another write comes thru, would the second write erase the data from the first?

THanks and have a great day.

To answer your questions as succinctly as possible:

The buffered writing mechanism buffers data until the database can get around to writing it OR until the data cache can get to it. Therefore, it should not normally need to hold a lot of data, usually in the worse case around 30 seconds worth.

By default, it holds 500 records (for each defined database connection). You can change this under Settings->Service Settings. This means that if you have one group running every second, it will hold up to 500 seconds of data. If you had 250 groups at 1 second, it would only store 2 seconds, so you’d probably want to increase it.

If the queue gets full, no data is lost, but instead the group begins to behave as it normally would if buffered writing wasn’t turned on- it will block until a row is removed and it can insert into the queue.

Don’t worry too much about the mention of threads, it’s just a side note and consequence to how the buffered writing is designed. Not really a big deal.

Hope this answers your questions,

ok so if I understand this I have 100 standard groups, 2 block groups and 3 timed groups, the block groups have the buffer turned on automatically by default.

Is that a correct statement?

Now say that the SQL server becomes bogged down and can not accept the writes as fast as FSQL sends them. If I have this feature turned on then it will buffer the writes.

Is this correct?

Now when you say 500 records, how is that broken down? I mean if you have say 50 items in each group does it take all this data as one record or does it count each piece?

Also does buffering speed up the data capture? I ask this because since I have turned this feature on I sometimes get a row of data in my SQL database where not all the fields were updated. I did not get this before, or at least I dont think so, but this seemed like a good feature to impliment so I did it. Now when I do my error queries the database team and I have come up with we are seeing occasional hits where this happens. Since this was the last thing changed I wanted to make sure if it had anything to do with this issue.

As for the rest of your write up it is very clear and much appreciated.

[quote=“Colby.Clegg”]To answer your questions as succinctly as possible:

The buffered writing mechanism buffers data until the database can get around to writing it OR until the data cache can get to it. Therefore, it should not normally need to hold a lot of data, usually in the worse case around 30 seconds worth.

By default, it holds 500 records (for each defined database connection). You can change this under Settings->Service Settings. This means that if you have one group running every second, it will hold up to 500 seconds of data. If you had 250 groups at 1 second, it would only store 2 seconds, so you’d probably want to increase it.

If the queue gets full, no data is lost, but instead the group begins to behave as it normally would if buffered writing wasn’t turned on- it will block until a row is removed and it can insert into the queue.

Don’t worry too much about the mention of threads, it’s just a side note and consequence to how the buffered writing is designed. Not really a big deal.

Hope this answers your questions,[/quote]