Can query rules, data stores, and the other Appian out of the box supported data

Hi Jorge, Can you give me some more information about what you're trying to achieve? Are you talking about the primary data source or a business data source?

We certify the database support with the TRANSACTION_READ_COMMITTED transaction isolation level as given in the documentation (forum.appian.com/.../Configuring_Relational_Databases) for a couple of reasons.

First, Oracle creates tables with an INITRANS setting of 1 by default, which causes an error (ORA-08177) when creating the schema from a Data Store using a connection with a transaction isolation setting of SERIALIZABLE because an INITRANS setting of 3 is required for that transaction isolation level. Even if you worked around that by creating your schemas manually with INITRANS of 3 and then just verifying them via the Data Store interface, you'd run into the second issue.

The second issue is that in our testing we found that having a transaction isolation setting of SERIALIZABLE did not perform well with multiple concurrent reads and writes to the same table. It ended up in a high number of deadlocks. This problem was not specific to Oracle. We saw it with the other supported database vendors as well.

Hi Jorge, Can you give me some more information about what you're trying to achieve? Are you talking about the primary data source or a business data source?

We certify the database support with the TRANSACTION_READ_COMMITTED transaction isolation level as given in the documentation (forum.appian.com/.../Configuring_Relational_Databases) for a couple of reasons.

First, Oracle creates tables with an INITRANS setting of 1 by default, which causes an error (ORA-08177) when creating the schema from a Data Store using a connection with a transaction isolation setting of SERIALIZABLE because an INITRANS setting of 3 is required for that transaction isolation level. Even if you worked around that by creating your schemas manually with INITRANS of 3 and then just verifying them via the Data Store interface, you'd run into the second issue.

The second issue is that in our testing we found that having a transaction isolation setting of SERIALIZABLE did not perform well with multiple concurrent reads and writes to the same table. It ended up in a high number of deadlocks. This problem was not specific to Oracle. We saw it with the other supported database vendors as well.