On Sep 16, 2007, at 1:01 PM, Robert Ian Smit wrote:
[root:dev_tempstorage_db] select length(value) from caches; +---------------+ | length(value) | +---------------+ | 67694 | +---------------+The problem was not caused by a distinction between text and blob cols, but rather by the maximum colsize of these types. Changing to either longtext or longblob will equally solve the problem.
Ah, I'll change it to longblob then, does this limitation of blob size apply to all db's?
How would you implement locking in the case of mulitple app servers? Currently each app server uses its own set of lockfiles. Is it conceivable and preferable that locking is done in the database for ext:database namespaces? If so I might look into it.
The locking in Beaker when using ext:database is to try and minimize how many processes/threads on the *same* machine might end up re- generating a cached. The db already handles locking during commits so if 2 processes on different machines end up regenerating the same cached file at once (which is ok), the last one to commit wins. Not really any tolerable way to avoid that, and the locking does at least limit redundant expired regenerations on the same machine.
Cheers, Ben
smime.p7s
Description: S/MIME cryptographic signature
