Thanks for all the responses. I don't have a great deal of time to devote to researching the various options because of a tight schedule. I was hoping that this is a scenario that is commonly encountered and that there would be a ready answer but I guess that's not the case.
I will probably end up using a load testing tool eventually but for now I guess I might have to just press on and hope that I've implemented transaction isolation correctly. (I hate unrealistic schedules) Gary Michael Horwitz wrote: > > There are numerous ways of doing this - if you choose to approach this by > spawning separate threads for each concurrent access you may want to take > a > look at the multithread JUnit extensions: > http://www.junit.org/news/extension/threaded/index.htm > > Have not used them myself, but they look like a good place to start! > > I would still recommend testing with a tool such as Grinder - although > formally a load testing tool, it is very useful for highlighting any > unforseen concurrency issues early on in development, particularly when > such > issues only become apparent once the application is under load. > > Mike. > > > On 12/8/06, Bryan Noll <[EMAIL PROTECTED]> wrote: >> >> A real simple way to do it is to write an object that extends Thread, and >> implement its run method to do the 'concurrent' piece work. >> >> Meaning, in a junit test, let's say a method named... >> testConcurrentStuff.... one example could be.... >> >> >> 1. Look up an object with id = x >> 2. Modify that object in some way... change a property value for >> instance >> 3. Construct a new instance of the class you wrote that extends >> Thread - this is the one that is acting as the 'sneaky' modifier... or >> the >> one that is going to be the first user to the punch in terms of >> modifying >> the same object with id = x. >> 4. Call the start method on this thread object, all of this is >> implemented in the run() method of your Thread extending class >> 1. Looks up the same object with id = x >> 2. Modifies it >> 3. Saves it - successfully >> 5. Right after you started the Thread (in the original test that >> is), join it via a call to threadExtender.join() - this means that >> the original thread, aka... the one that junit started for you in your >> test >> method, will wait until the thread you spawned is complete >> 6. Try to save the object you looked up and modified in steps 1 and >> 2 >> 7. If using hibernate, you'll receive an exception telling you that >> says something regarding an optimistic locking problem... >> >> Hopefully this is something like what you were thinking of.... >> >> --Bryan >> >> On 12/7/06, GaryW <[EMAIL PROTECTED]> wrote: >> > >> > >> > Thanks for the reply Matt. >> > >> > I don't know if I worded my question correctly. I don't really want >> > load >> > testing; I'm just looking for a way to simulate 2 conflicting updates >> to >> > see >> > if I get the expected exception/behavior based on the transaction >> > isolation >> > settings/code. Is this possible using JUnit? >> > >> > Gary >> > >> > >> > >> > Matt Raible-3 wrote: >> > > >> > > I'd recommend using something like WAPT or Grinder. These are the >> two >> > > major >> > > load testing tools I'm aware of. I believe TestNG also supports >> > running >> > > concurrent tests on separate machines. >> > > >> > > Matt >> > > >> > > On 12/7/06, GaryW <[EMAIL PROTECTED]> wrote: >> > >> >> > >> Does anyone have any advice on how to set up tests to simulate >> > concurrent >> > >> updates in order to test transaction isolation? I'm using >> > >> Spring/Hibernate. >> > >> Thx, Gary >> > >> ------------------------------ >> > >> View this message in context: Testing transaction >> > >> isolation?< >> > >> http://www.nabble.com/Testing-transaction-isolation--tf2776210s2369.html#a7744788 >> > > >> > >> Sent from the AppFuse - >> > >> User<http://www.nabble.com/AppFuse---User-f2370.html>mailing list >> > archive >> > >> at >> > >> Nabble.com <http://nabble.com/> . >> > >> >> > > >> > > >> > > >> > > -- >> > > http://raibledesigns.com >> > > >> > > >> > >> > -- >> > View this message in context: >> > >> http://www.nabble.com/Testing-transaction-isolation--tf2776210s2369.html#a7748418 >> > Sent from the AppFuse - User mailing list archive at >> Nabble.com<http://nabble.com/> >> > . >> > >> > --------------------------------------------------------------------- >> > To unsubscribe, e-mail: [EMAIL PROTECTED] >> > For additional commands, e-mail: [EMAIL PROTECTED] >> > >> > >> > > -- View this message in context: http://www.nabble.com/Testing-transaction-isolation--tf2776210s2369.html#a7760622 Sent from the AppFuse - User mailing list archive at Nabble.com. --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
