This week's book giveaway is in the OO, Patterns, UML and Refactoring forum. We're giving away four copies of Refactoring for Software Design Smells: Managing Technical Debt and have Girish Suryanarayana, Ganesh Samarthyam & Tushar Sharma on-line! See this thread for details.
I have written an application that reads data from a database, displays the data on a JTable that can be modified with edits, insertions and deletions that thereafter update, insert or delete database tables. I am using vector as the underlaying data structure. I have read somewhere that vectos are thread safe, meaning, correct me if I am wrong, that a vector's additions or removal operatons coming from one thread are blocked until another thread completes its additions or removal operations. I am not using threads; this is a single threaded application; but since this application is going to be distributed to several users, and there will be several database connection requests, I have included a serializable isolation statement and implemented transactions so that no dirty reads, phatom reads and no-repetable reads may occur. My question is; since several users are going to be using the application and therefore the application vectors are going to be read and modified by several users at the same time; should the fact that vectors are synchronyzed take care of any problems or is there any thing else I should do to make sure that a vector is not modified in any way until one user's process has completed?
Vectors give you nothing in this case, they don't work cross process, you have multiple threads just not in the same process and they only communicate via the database.
Presumably its all down to how you have implemented transactions.
Normally you lock the data in the database to prevent concurrent writes such that one user must complete first or allow a subsequent transaction commit to fail based on change having happened (optimistic) and rollback the dirty write.
"Eagles may soar but weasels don't get sucked into jet engines" SCJP 1.6, SCWCD 1.4, SCJD 1.5,SCBCD 5
Joined: Jul 15, 2011
Thank you for your response. I do not anserstand very well this part "Vectors give you nothing in this case, they don't work cross process, you have multiple threads just not in the same process and they only communicate via the database." Does this mean that since this is not a multithreaded application, vectors do not take care of synchronization because there is nothing to synchronize and that since the threads are issued by the database, the concurrency control depends in the transactions impementation?
Vectors would synchronize two threads in the same process only, as your threads are in separate processes / applications they can't communicate with each other and have their own instance of the vector. In a single threaded application the synchronization of vector is not useful (does nothing).
The other problem with your original post: whatever you read which said that Vector is "thread safe" was incorrect. It isn't. Sure, all of its methods are synchronized, but that isn't enough to provide full thread safety.
However as Chris says, it's irrelevant in your situation anyway.