Yes - you have it right. We provide SQLAnywhere with the partition size and an identifier for each database - and it generates keys in the proper range. On Mon, Mar 22, 2010 at 1:22 PM, Ceki Gülcü <ceki@qos.ch> wrote:
If I understand correctly, the event_id keyspace is partitioned among multiple databases which are synchronized with a central database. Thus, the partitioning is done by the databases and is transparent to DBAppender. I did not know you could partition the key space like that.
On 22/03/2010 9:13 PM, Michael Lynch wrote:
It is mostly out of caution with some amount of fatalism mixed in.
We are working with a distributed databases that is synchronized back to a central database. In order to avoid key collisions we are partitioning the key space. We may have as many as 100 remote databases - reducing the key space for any one to ~21million.
While I don't expect 21 million errors from a single instance (nor even all together), there are processes that can run every few seconds that can generate an error. Left unchecked/unnoticed for long enough and the volume of errors could add up over time.
In my experience there is very little memory or disk space issues created by using a long instead of an int - although I recognize that logback is used in many different ways/environments, so my experience may not be as accurate in the context of logback.
- Michael
_______________________________________________ logback-dev mailing list logback-dev@qos.ch http://qos.ch/mailman/listinfo/logback-dev