session_set_save_handler()の仕様を理解する必要は通常有りません。
セッションの保存方法がDB等に変更されているだけで、特別な違いは無いと考えて良いです。

> そこでEC CUBEでは、通常のセッションの他にDBで管理しているセッションがありました。
> PHP.iniの設定を変更し、短い時間でタイムアウトを起こそうとしても
> DBで管理しているセッションが存在す限りセッション切れにならないようです。
> その有効期限は、mtb_constants.phpの「MAX_LIFETIME」で管理されていました。

PHPセッションは、その保存先がファイルであれDBであれ、php.ini等で設定した期間以上更新が無いものをガベージコレクションの対象にし、セッションIDと関連するデータを削除します。
また、ガベージコレクションは毎アクセスごとには行なわれず、同じくphp.ini等で設定した確率に従って実行されます。
EC-CUBEのSC_Helper_Session::sfSessGc()はガベージコレクション時に実行される処理である為、MAX_LIFETIMEをどのように設定しても、ガベージコレクション自体が確率で制御される限りは確実にMAX_LIFETIMEでセッションが無効になる事は保証されません。
うろ覚えですが、ガベージコレクションが行なわれない限り、PHPセッションは生きていると考えて良かったはずです。


> また、通常のセッションが切れてDBのセッションが切れていない場合や
> 通常のセッションは切れず、DBのセッションが切れた場合のセッションIDは
> どうなっているのでしょうか？

セッションCookieの生存と、PHPセッションの生存を混同されているように思われます。

hatakeさんが言われる「通常のセッションが切れ（セッションCookieが失効）」「DBのセッションが切れていない（PHPセッションは生きている）」場合、何らかの方法でセッションIDを指定されるとPHPセッションは継続して使用されます。
「通常のセッションは切れず（セッションCookieは有効）」「DBのセッションが切れた（PHPセッションが削除）」場合は、そのセッションIDで新規の（空の）セッションが作成されます。


Zend Frameworkでもセッションの有効期間管理はプログラムで行なっていますので、PHPのセッション機構のみではセッションタイムアウトを実現できないと考えたほうが良いです。
ほんの数行プログラムに書き加えるだけで十分機能します。

----------------
pantacle
http://pantacle.net/