This content has been marked as final. Show 7 replies
I think the best solution for all your requirements would be to have a servlet context listener intiialize everything and set the respective attributes in application scope. Each servlet could get their own refs and have access to the shared env cache.
Have a look at this article here, which discusses something similar.
As for the EntityIndex'es, yes they are thread-safe and you can use the same approach as for the Environment, EntityStore etc refs (get the respective index ref, as an attribute, from the ServletContext).
If this does not work for you let me know and I can look for other solutions.
Hi Andrei, thanks for the link, this approach is perfect for my requirements.
With regard to sharing index refs. across threads etc. still a bit conflicted as to what the best practice is ie. are there good reasons not to do it? Time taken to build the refs. on each request seems negligible, I'd be interested to know what others do and perhaps why. Also are there a group of 'best practise patterns' for berkelydb je development?
Thanks again, much appreciated.
For simplicity it is best to have a single Environment instance and a single EntityStore (or Database) instance per store (or database). There is little or no performance impact of sharing these objects among threads.
EntityCursors (or Cursors), on the other hand, should always be per-thread and closed as soon as possible.
There is a section at the end of the Getting Started Guide about multi-threading and additional information in the FAQ.
Hi Mark, to confirm, it's fine to treat index object refs. in the same way as environments and stores - meaning share between threads - but everything below (created from) indexes, should be created/destroyed per request, agreed?
Cheers for you input.
Yes, EntityIndex objects are also thread-safe. Really only EntityCursor objects are not.
The entity objects themselves are not owned by JE. You will have problems if you have multiple threads changing them concurrently (if one thread is changing an entity object's properties and another thread is storing it, for example). However, it is up to you if you want to share entity objects between threads; there is nothing wrong with that, since there is no interaction with JE. But your app will need to enforce thread safety, perhaps by using them only in a read-only fashion, for example.
Andrei & Mark, thank you kindly :o)