I think we can fix CAY-2040 by ensuring a separate transaction (maybe in a
separate thread) for filling the app PK cache. The more I think about it, the
more sense it makes. It is really separate from the main tx.
Andrus
> On Dec 4, 2015, at 12:45 PM, Aristedes Maniatis wrote:
>
> On 3/12/20
On 3/12/2015 2:08pm, John Huss wrote:
> The main advantage of a native solution is that you know it works. If you
> ever used native PK generation the AUTO_PK_SUPPORT table feels very
> kludgy. It works (I guess?), but it's not ideal. A native solution is
> faster and simpler. It handles transa
The other reason for the auto_pk_support is that a custom db adaptor is
needed to use native pks, and that isn't always immediately available.
On Wed, Dec 2, 2015 at 9:08 PM John Huss wrote:
> The AUTO_PK_SUPPORT table exists only to support PK generation for DBs
> that do not have native support
The AUTO_PK_SUPPORT table exists only to support PK generation for DBs that
do not have native support for it built in. However, in this day and age
any database worth using has this built in. I've run production apps with
Postgres, MySQL, FrontBase, and Interbase / Firebird, and all of them have
I've always used the AUTO_PK_SUPPORT approach to PK generation, all the way
back from WebObject EOF days many many years ago.
However a recently discovered bug in this approach [1] and how it intersects
with transactions may require use to think about going over to database
generated primary ke
