If you refer to collections or maps that are part of the Java2 framework as not being syncronized, then you don't have to worry about syncronization when you don't have a multi-threaded application. BUT... if you are talking J2EE and you have your collection deployed as something in an ejb or helper class, and the container such as weblogic or websphere is managing the threads, then does that mean it doesn't matter if you use a syncronized class like vector or hashtable (overhead with syncronization), versus a list or map (no overhead for syncronization). I understand the concept, except when it applies to applications deployed in a container. THANKS for your thoughts.
OK, the basic answer here is that if you do things in your EJBs the right way this will never, ever, ever be an issue. Let's talk about the EJB types: (1) Session beans -- remember these come in two types, stateful and stateless. In a stateless EJB you should never have an instance variable that is read/write -- therefore the type of collection should never be an issue. In a stateful bean, the container guarantees that only one thread at a time will ever use any bean implementation. So it's not an issue there since the class is basically always single-threaded. (2) Entity beans -- this is a little tricker. Remember that they come in two forms: CMP and BMP. In a CMP bean you can (or should) only have variables of the types that map to your database. Collections should only be those that are used to represent object relationships -- in any case the container both generates the code and handles the threadsafety issues, so you're safe no matter what. So that leaves only one type of object that you have to think about -- BMP Entity Beans. In a BMP entity bean you can declare any variable of any type you wish. It's only here that it becomes an issue. Now there are some interesting issues that could crop up here with regard to which collection type you choose -- I'll have to think about that, read the specs (both the 1.1 and 2.0 spec), mull it over and get back to you...anyone else want to add comments in the meantime? Kyle
Any attempt to *persist* a collection in Entity EJBs would have to be considered carefully - all it takes is a minor change in the serialized format to turn all your persistent collections into pet food. Of course, there *is* a type of persistent collection that EJBs handle very well. It's called a database table backing an Entity EJB. And synchronization for *that* is supported very well!
Sources may include data from the Fakebook Research Foundation with support from Gargle University