BlockingCache has a risk of OOM

[zhangweidavid]

Hi:

I think this class may has a risk of OOM .What do you think @harawata ?

https://github.com/mybatis/mybatis-3/blob/master/src/main/java/org/apache/ibatis/cache/decorators/BlockingCache.java

[harawata]

Because entries in locks are never removed?
It seems to be possible, technically.

I found a SO thread discussing this exact subject.
https://stackoverflow.com/a/41912651
So, should we change BlockingCache to use CountDownLatch as proposed in the accepted answer?
Or do you have another idea?

[zhangweidavid]

I think it's a good idea.

[kezhenxu94]

It's a good idea but this may bring new bug when caching is enabled and continuous queries are called, here is my test case to reproduce it.

The problem is that the org.apache.ibatis.cache.decorators.TransactionalCache#putObject won't actually put the object to the delegated cache (BlockingCache here), causing the lock not to be released and later calls to getObject in the same thread blocked.

I don't know it's a bug of TransactionalCache or BlockingCache, I had open a PR #1358 to fix this bug based on the original implementation of BlockingCache, if we are to change BlockingCache to use CountDownLatch, how to deal with this bug? What do you think @harawata

[harawata]

I have submitted #2044 as a fix.
Let me know if you notice anything!