Gringotts is not thread safe...

I will attempt to get some stack traces... And more. Or I will attempt to fix it on my fork.

EDIT:

For all those that need an immediate fix you may use the latest towny version that.
Some of my pull reqs for several fixes have gone through. Including a temporary work around to this bug.

There is a new setting in the settings file under the economy section.

Which its default is this.

  use_async: 'true'

Setting it to false will force towny to be synchronise with the server thread thus the error will no longer occur.

  use_async: 'false'

So, at last, here's a dev version addressing this issue:
https://dl.dropboxusercontent.com/u/10988727/Gringotts-2.9-SNAPSHOT.jar

Would appreciate feedback on whether it works for you

I'll just go ahead and assume this works now ...

Hi, did you have any success with the fix?

I have started today though.

Sorry have not started work on it due to my server custom plugins needing work.

Cool, good to hear!

For all those that need an immediate fix you may use the latest towny version that.
Some of my pull reqs for several fixes have gone through. Including a temporary work around to this bug.

There is a new setting in the settings file under the economy section.

Which its default is this.

  use_async: 'true'

Setting it to false will force towny to be synchronise with the server thread thus the error will no longer occur.

  use_async: 'false'

Very nice! Do you have any idea where to look about the thread safety issues in Gringotts? I might have some time to work on it.

The database access to both derby and SQLite should be thread safe, but apparently the world access from an async task isn't, as seen in this stack trace: http://pastebin.com/4TurFgWC

I'd be very wary of any kind of cache of changing data. The most reasonable thing seems to be scheduling a synchronous task to complete the econ action. See http://wiki.bukkit.org/Scheduler_Programming

The bug occurs in your DB stuff that fetches chest contents. Specifically location stuff.

But it is entirely possible to also be the fact reading chest contents

Best option and only is most likely to have a cache of values in chest that update on inventory interaction between tracked chests.

Making sure the cache is multi thread safe.