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.