On Oct 6, marc fleury quoth:
> > Hi!
> >
> > marc fleury wrote:
> > > 3- LOCKS 10 threads on one object: loop many iterations and
> > look for lock
> >
> > Could also be a good idea to test deadlock handling, i.e. 10 threads
> > using 2 objects in random order within one transaction. Should lead to
> > lots of deadlocks.
>
> right, but we don't do anything right now...
>
> how common are deadlocks in operations? (not theory)
Theoretically (:-O), deadlocks would never occur in a properly coded
application and that's the problem. They are very common in reality. The
container must detect them and eliminate them.
In the theoretical world, all clients would acquire resource locks in the
same order to prevent such a thing from occuring. The real issue is that
the container cannot allow 'bad' code to take it down by locking it up
indefinately nor destroy 'good' code's efforts by arriving at a deadlock
and not being able to resolve it without restarting the container.
In my experience, I've seen the inability of many database systems to
manage or even detect deadlock lead DBAs to remove the RI checks and
implement periodic 'cleansing' and manual integrity checks instead. It's
messy but it works.
A container that can detect and back out deadlock by aborting the
in-progress transactions is worth its proverbial weight in gold. The real
problem is transaction queueing though. Once you break the deadlock, if
it is one rogue transaction, when it retries, it will merely lockup with
the next tx in the queue. You can end up with a huge mess that is only
reparable with a restart. I've only seen a few systems that aren't
journal based operate live *with* RI checks in place. That's not to say
it doesn't work for some people. After all, I tend to run with people in
the same circles and it may simply be an aspect of my industry.
C=)
--------------------------------------------------------------------------
The fact that no one understands you doesn't mean you're an artist.
--------------------------------------------------------------------------
Caskey <caskey*technocage.com> /// TechnoCage Inc.
--------------------------------------------------------------------------
Oh no! Space monkeys are attacking! -- eddie izzard
--
--------------------------------------------------------------
To subscribe: [EMAIL PROTECTED]
To unsubscribe: [EMAIL PROTECTED]
Problems?: [EMAIL PROTECTED]
