As roboticus says - open two or more database connections (or client apps) and run requests with varying degrees of delays.
in reply to Testing transactions
I presume that the transactional part of the system is handled at the database level. Even so, if Dbix::Class offers a high level of abstraction over what actually happens in the DB (something I don't know as I haven't used it) then you should be careful of things like deadlock situations where locks on different resources are acquired in a different order in two processes, and each process is waiting to acquire a lock that the other already holds.
And keep in mind that you are likely to find race conditions in places where you didn't think that they were likely to appear...