JCR interfaces should be thread safe whenever possible

Most of the JCR interfaces are not expected to support concurrent access by multiple threads, and this was what we did for the 2.x releases. However, this caused a number of strange problems when users did (accidentally or intensionally) use a Session in multiple threads. (For example, when an event listener used the same Session that it was registered with to read content; the listeners are called in separate threads, so multiple listeners could end up using the same Session.)

It would be very nice if the Session, Node, Property and Workspace implementations were thread safe. Users would no longer run into any issues like those described above, and with the new 3.x design we have an opportunity to make the implementations thread safe using concurrent collections and techniques (and locks only where required) while avoiding synchronization.