Win a copy of Kotlin in Action this week in the Kotlin forum!
  • Post Reply Bookmark Topic Watch Topic
  • New Topic

Syncronization and collection classes  RSS feed

 
Amy Roberts
Greenhorn
Posts: 5
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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.
 
Kyle Brown
author
Ranch Hand
Posts: 3892
5
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
 
Tim Holloway
Bartender
Posts: 18704
71
Android Eclipse IDE Linux
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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!
 
Giri Prasad
Ranch Hand
Posts: 56
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Can the Collections in the whole discusion be replaced with any non-synchronized java class?

Thanks
 
It is sorta covered in the JavaRanch Style Guide.
  • Post Reply Bookmark Topic Watch Topic
  • New Topic
Boost this thread!