ThreadLocal.remove(), J2EE, and com.hp.hpl.jena.tdb.transaction.DatasetGraphTransaction

[Jeremy Carroll <je...@topquadrant.com>]

For me I have to take care with thread locals both in our own code and 
in a variety of 3rd party code, because of the possibility of 
classloader mem leaks in a J2EE/OSGi environment.

See e.g.
https://issues.apache.org/jira/browse/SHINDIG-1132
for general background to this sort of problem

As a result, I track down and treat specially ThreadLocals which do not 
call remove() in an appropriate fashion.
i.e. a well behave thread local, will call remove(), hopefully in a 
finally block, as the thread exits back up the stack.

Sometimes this is difficult or impossible, and obviously some 3rd party 
code I cannot influence very much, so I have workarounds.

In com.hp.hpl.jena.tdb.transaction.DatasetGraphTransaction there are two 
thread locals, neither of which call remove() appropriately. In 
particular, remove() cannot be called on the finalizer thread.
Note, remove() does not create the ThreadLocal if it currently has no value.

My suggestion would be to call remove on both ThreadLocals in this class 
on all of the methods that exit a transaction (end(), abort(), commit()).
I would be happy to provide a patch to this effect, (I realize I already 
owe a couple of patches)

For more background, see e.g.
http://cs.oswego.edu/pipermail/concurrency-interest/2007-October/004476.html
for some more discussion. This general situation is made a lot worse by 
the previously mentioned JVM bug, which can create issues with weak 
references as well as strong - given that this is a GC bug that I do not 
understand it is very hard to know which weak references matter and 
which don't.
http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7146977


Jeremy

Re: ThreadLocal.remove(), J2EE, and com.hp.hpl.jena.tdb.transaction.DatasetGraphTransaction

[Andy Seaborne <an...@apache.org>]

On 05/09/12 17:57, Jeremy Carroll wrote:
> For me I have to take care with thread locals both in our own code and
> in a variety of 3rd party code, because of the possibility of
> classloader mem leaks in a J2EE/OSGi environment.
>
> See e.g.
> https://issues.apache.org/jira/browse/SHINDIG-1132
> for general background to this sort of problem
>
> As a result, I track down and treat specially ThreadLocals which do not
> call remove() in an appropriate fashion.
> i.e. a well behave thread local, will call remove(), hopefully in a
> finally block, as the thread exits back up the stack.
>
> Sometimes this is difficult or impossible, and obviously some 3rd party
> code I cannot influence very much, so I have workarounds.
>
> In com.hp.hpl.jena.tdb.transaction.DatasetGraphTransaction there are two
> thread locals, neither of which call remove() appropriately. In
> particular, remove() cannot be called on the finalizer thread.
> Note, remove() does not create the ThreadLocal if it currently has no
> value.

DatasetGraphTransaction is the long lived holder for a dataset. Not as 
long lived as StoreConnection, the more important class.

> My suggestion would be to call remove on both ThreadLocals in this class
> on all of the methods that exit a transaction (end(), abort(), commit()).
> I would be happy to provide a patch to this effect, (I realize I already
> owe a couple of patches)

Yes for the txn ThreadLocal (caveat: there are different exit sequences 
for READ and WRITE transactions).

However, the boolean inTransaction records the state of the created 
dataset for this thread and is a check against misplaced 
begin/commit|abort/end and so serves a function beyond the life of a 
single transaction.

The inTransaction thread local can't be moved into StoreConnection 
because you can have several DatasetGraphTransaction on the same thread 
in different states.

	Andy

BTW If, via classloaders, you get different multiple StoreConnection 
classes, then there are 2 managers of the same persistent state. 
Disaster will occur.

>
> For more background, see e.g.
> http://cs.oswego.edu/pipermail/concurrency-interest/2007-October/004476.html
>
> for some more discussion. This general situation is made a lot worse by
> the previously mentioned JVM bug, which can create issues with weak
> references as well as strong - given that this is a GC bug that I do not
> understand it is very hard to know which weak references matter and
> which don't.
> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7146977
>
>
> Jeremy
>
>
>
>