Discount on my new book for Db2-L subscribers [AD]

Craig Mullins

Discount on my new book for Db2-L subscribers [AD]

I am offering a 5% discount on the ebook edition of my latest book, A Guide to Db2 Application Performance for Developers. The book offers guidance and direction to Db2 application developers and programmers on how to write efficient, well-performing programs. This book is written for all Db2 professionals, covering both Db2 for LUW and z/OS. When there are pertinent differences between the two it is pointed out in the text.

The book’s focus is develop­ing applications, not database and system administration. The goal is to educate developers on how to write good appli­cation code that lends itself to optimal performance. By following the principles in this book you will be able to write code that does not require significant remedial, after-the-fact modifications by performance ana­lysts. Follow the guidelines in this book and your DBAs and performance analysts will love you!

To order, use code db2l5off when you check out at https://tinyurl.com/db2-craig

Again, this offer is for the ebook edition only.

Feel free to share this offer with your development teams.

Regards,
Craig S. Mullins
Mullins Consulting, Inc.
http://www.mullinsconsulting.com
IBM Gold Consultant and IBM Champion for Analytics

Jeff Goss

RE: Discount on my new book for Db2-L subscribers [AD]
(in response to Craig Mullins)

Interesting.  As a DB2 LUW developer that has worked a lot in locking and concurrency I'm wondering how much of this is covered in the book?  In particular I find a lot of customers end up coding to the implementation of the isolation level, for instance depending on row locking by one application to block/serialize another, and not to the definition of the isolation level and what it guarantees or doesn't guarantee, especially with Cursor Stability.  For instance, when we made an optimization to not lock rows on a page that is known to have committed data by the pageLSN, some applications stopped working because they depended on the X row lock held by another that hadn't updated the row ie. they were using the row lock to serialize.  Others have yet to make the jump to enabling Currently Committed for CS/RS for similar types of logic breaking their application programs, with some even claiming we returned 'incorrect' results when in reality we conform precisely to the isolation level just not the old implementation.

Of course we added lots of ways to mitigate this at the database, application, and even SQL statement level with things like registry variables and the WAIT FOR OUTCOME syntax (turns off essentially every performance enhancement we've built in the last 20 years ;-) ).  However in these cases applications can end up with a lot of performance and timeout failure issues based on concurrency issues with locking.

Also, although you say this is not aimed at DBAs, do you cover topics like indexes and statistics which are probably the two most important factors affecting query performance?