Concurrent usage of image mosaic with heterogeneous CRS, against a database index, can cause deadlock
This is due to the mosaicking machinery opening a visitor against the index (one connection open) and needing to compute, on occasion, the bounding box of granules matching a certain CRS, while iterating. This causes a second connection to be open while the first is still being used for the main visit.
In case there is a connection pool with maximum fixed connection size, and concurrent clients asking for mosaic reads, this can cause the pool to be exhausted blocking attempt to compute more bboxes. As as example, picture a pool with a max size of N, and N threads that manage to open the visitor, exausting the connection pool, and then trying to compute bboxes on top of it (none of them will be able to).
The CRSs specific BBOX should be computed before the index visit starts.
Another theoretical solution would be to allow using the same connection for both the visit and the bbox calculation of a given thread (possible, a connection can have as many resultsets open as it sees fit), however the FeatureSource/Collection API are not helping, to do that, the operations would have to be wrapped by the same Transaction (not available on FeatureSource, but only on FeatureStore).