Let us first address a potential issue in your code snippet - each time getConnection
is called a new connection pool is created. This represents a resource leak as, most likely, a single connection pool would be sufficient. I would suggest the following refactor:
@Singleton
class OlapConnectionPool () {
private val ds = {
val dataSource = new SimpleOlapDataSource
val config = new GenericObjectPool.Config
//... some connection code
new PooledOlapDataSource(dataSource, config)
}
def getConnection() = ds.getConnection()
def close() = ds.close()
}
Here ds
is initialised only once upon singleton construction, so there is a single connection pool for the life-span duration of the singleton.
Singletons are thread-safe as longs as they are not publicly exposing shared state, for example, via public var
members, and all the dependencies of the singleton are also thread-safe. Hence we need to determine if the dependency PooledOlapDataSource
is thread-safe. I am guessing PooledOlapDataSource
is from pivot4j
, so inspecting PooledOlapDataSource
source code we can see it depends on PoolableObjectFactory
, which according to docs is thread-safe:
PoolableObjectFactory must be thread-safe.
Furthermore if we inspect dependencies of PoolableObjectFactory.getConnection
we arrive at borrowObject
call where we see bunch of synchronized
sprinkled in. Therefore it is probably safe to conclude your singleton is thread-safe.
Also, have a look at this interesting answer where the author recommends to:
In general, it is probably best to not use @Singleton unless you have
a fair understanding of immutability and thread-safety.