I found out that Liferay now by default creates 2 JDBC data sources (and pools), one for regular liferayDataSource and one for counterDataSource. This is clearly visible in JMX console. The connection properties are reused and can be overridden, as said in portal.properties:
# The counter operates with its own data source to prevent deadlocks. By
# default, the data source created for the counter uses the same settings as
# those used to create the data source used for the rest of the portal. That
# happens because the counter service will look up the properties prefixed
# with "jdbc.default." to create its data source. See the JDBC properties
# prefixed with "jdbc.default." for more information.
# Setting a different value for the counter JDBC prefix allows you to better
# fine tune the counter data source with its own set of configuration
# settings for high availability installations. Note that these settings,
# though separate, are a copy of the default settings with the newly
# overridden values.
However I found out that if you set up:
Then Liferay most likely uses only one pool - counterDataSource will use the same as the default DS (the pool fetched from JDNI).
Is this an issue? Would users see potential deadlocks if they set up their JDBC pool using app server and JNDI? Should we instruct users, that two separate pools need to be created in app server in order for Liferay to work as expected?
I assume the correct set of properties for using JNDI should be: