1

I have an ArrayList of objects that may be added/deleted/updated via REST calls. In order to prevent issues that may result from concurrent accesses, will a ReadWriteLock be appropriate, and efficient?

  • What are you using this ArrayList for? – Robert Harvey Jul 8 '16 at 17:06
  • I am storing Entry objects that contain several pieces of information about a user (e.g. name, address) – SVN600 Jul 8 '16 at 17:07
  • What is your server? Node? – Robert Harvey Jul 8 '16 at 17:12
2

A database with ACID guarantees is almost certainly a better way to do this than attempting to maintain an ArrayList in memory, for several reasons:

  1. It will scale.
  2. It will maintain REST's stateless guarantees.
  3. You don't have to worry about the dog tripping over the power cord.
  4. The concurrency is already done for you.

If you need extremely fast turnaround on data that doesn't change much, consider adding a cache like Redis or using memoized objects that are populated from your database.

| improve this answer | |
0

It's actually pretty simple, a Synchronized version will do just fine, it will make all access to the list safe EXCEPT in the case where you need to iterate over it. If you need to iterate over it, there are a couple ways.

  • Create a copy of the list then iterate over the copy (Note this will only copy the list's pointer array, not the objects in it--pretty quick operation).
  • put synchronized(list){} around the iteration loop--this will lock out the collection for the entire time of the iteration, but won't make a copy.

As for performance of synchronized operations, I wouldn't worry about it--it's going to be a few times slower than an unsynchronized list but a few orders of magnitude faster than hitting the disk.

Now, if a the object you retrieved from the list can be updated from two threads at once then it must have it's own internal synchronization mechanism (Often you can use business logic to preclude this possibility).

I would use this and then see if you have a speed problem, if you do there are patterns to avoid synchronization at all but it takes a bit more thought and coding. (The safest is probably using a list object from a Functional collection)

Going to the database as Robert suggests is better--do that first and if it's too slow only then cache the information internally.

| improve this answer | |
  • Why would a Synchronized version ever allow updating from two threads at once? Isn't that the whole point of thread synchronization, to prevent that from ever happening? – Robert Harvey Jul 11 '16 at 22:00
  • The object you get from the collection is independent from the collection. If you get it from 2 threads and operate on it from both, the ArrayList's synchronization isn't going to help at all. – Bill K Jul 11 '16 at 22:30
  • Oh. Defensive copying, in other words. Which will apparently happen twice if you iterate over a copy. – Robert Harvey Jul 11 '16 at 22:31
  • You only need defensive copying if you are going to iterate over the list. If you maintain your own pointer (For instance, if you only ever append to the end of the list an index would be fine) then you don't have to deal with it. It will be significantly faster than dealing with a DB, but as you said requires occasional saves if it's meant to be persisted. – Bill K Jul 11 '16 at 23:01

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.