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]
>
>
