RT 4.2 DB access through DB session pooler?

RT Users
1

Hi RT community,

We are working on an upgrade from RT 3.8.x to RT 4.2.x to get to a
supported version of RT and take advantage of the new features and
enhancements. In order to manage the PostgreSQL connections, we are
using pgbouncer. Pgbouncer has several types of pooling that can be
used: session, transaction and statement. The ‘transaction’ method
re-uses existing DB connections on a transaction (BEGIN/COMMIT)
boundary, while ‘session’ uses the same DB connection for each
fastCGI RT instance.

With RT 3.8.x we initially tried to use ‘transaction’ pooling, but
ended up needing to move to ‘session’ pooling because updates were
ending up in the wrong RT ticket. Is ‘transaction’ pooling not
usable? It would really help our multi-instance support if we could
use it instead of ‘session’. If it can be used, is there something
that needs to be done configuration-wise to have it work. Thank you
for any information that you can give.

Regards,
Ken

2

We are working on an upgrade from RT 3.8.x to RT 4.2.x to get to a
supported version of RT and take advantage of the new features and
enhancements. In order to manage the PostgreSQL connections, we are
using pgbouncer. Pgbouncer has several types of pooling that can be
used: session, transaction and statement. The ‘transaction’ method
re-uses existing DB connections on a transaction (BEGIN/COMMIT)
boundary, while ‘session’ uses the same DB connection for each
fastCGI RT instance.

With RT 3.8.x we initially tried to use ‘transaction’ pooling, but
ended up needing to move to ‘session’ pooling because updates were
ending up in the wrong RT ticket. Is ‘transaction’ pooling not
usable? It would really help our multi-instance support if we could
use it instead of ‘session’. If it can be used, is there something
that needs to be done configuration-wise to have it work. Thank you
for any information that you can give.

RT doesn’t make sufficient use of database transactions that I think
“transaction” will be reliable; I expect “session” is the best you can
get. I’m not aware of any configuration knobs that would affect this;
fixing it would take some internals development.

  • Alex
3

We are working on an upgrade from RT 3.8.x to RT 4.2.x to get to a
supported version of RT and take advantage of the new features and
enhancements. In order to manage the PostgreSQL connections, we are
using pgbouncer. Pgbouncer has several types of pooling that can be
used: session, transaction and statement. The ‘transaction’ method
re-uses existing DB connections on a transaction (BEGIN/COMMIT)
boundary, while ‘session’ uses the same DB connection for each
fastCGI RT instance.

With RT 3.8.x we initially tried to use ‘transaction’ pooling, but
ended up needing to move to ‘session’ pooling because updates were
ending up in the wrong RT ticket. Is ‘transaction’ pooling not
usable? It would really help our multi-instance support if we could
use it instead of ‘session’. If it can be used, is there something
that needs to be done configuration-wise to have it work. Thank you
for any information that you can give.

RT doesn’t make sufficient use of database transactions that I think
“transaction” will be reliable; I expect “session” is the best you can
get. I’m not aware of any configuration knobs that would affect this;
fixing it would take some internals development.

  • Alex

Thank you for the update. That is the behavior that we have observed
and will stick with the “session” pooling option.

Regards,
Ken