961931 - Need a way to know event of "msgDatabase open from CachedDB" and event of "msgDatabase close"

Status: NEW

(MailNews Core :: Database, enhancement)

Description

[WADA:World Anti-bad-Duping Agency]

Need a way to know following events.
- msgDatabase open from CachedDB
- msgDatabase close by mail.db.idle_limit,
  which invokes .msf file re-writing.
  (this is logged by MSGDB:5, but event is not notified)
- msgDatabase close which won't produce immediate .msf file writing.
  == this is perhaps reducing reference count of CachedDB

Currently, event which is notified to "OnEvent" listener of msgDatabase is "DBopened" event only.
> http://mxr.mozilla.org/comm-central/source/mailnews/db/msgdb/public/nsIDBChangeListener.idl#101

This is done at;
> http://mxr.mozilla.org/comm-central/search?string=HookupPendingListeners%28
> (1) by nsMsgDBService::FinishDBOpen
> http://mxr.mozilla.org/comm-central/source/mailnews/db/msgdb/src/nsMsgDatabase.cpp#350
> 350 NS_IMETHODIMP nsMsgDBService::CreateNewDB( ...
> 382   HookupPendingListeners(msgDB, aFolder);
> (2) by nsMsgDBService::FinishDBOpen
> http://mxr.mozilla.org/comm-central/source/mailnews/db/msgdb/src/nsMsgDatabase.cpp#296
> 296 void nsMsgDBService::FinishDBOpen( ...
> 312   HookupPendingListeners(aMsgDB, aFolder);
HookupPendingListeners() is defined at;
> http://mxr.mozilla.org/comm-central/source/mailnews/db/msgdb/src/nsMsgDatabase.cpp#277
> 291       m_pendingListeners.ObjectAt(listenerIndex)->OnEvent(db, "DBOpened");
HookupPendingListeners() is currently module for "OnEvent/DBOpened" event only.

FinishDBOpen() is called at three places;
> http://mxr.mozilla.org/comm-central/search?string=FinishDBOpen%28
> (i) OpenFolderDB
> http://mxr.mozilla.org/comm-central/source/mailnews/db/msgdb/src/nsMsgDatabase.cpp#92
> 92 NS_IMETHODIMP nsMsgDBService::OpenFolderDB( ...
> (ii) AsyncOpenFolderDB
> http://mxr.mozilla.org/comm-central/source/mailnews/db/msgdb/src/nsMsgDatabase.cpp#161
> 161 NS_IMETHODIMP nsMsgDBService::AsyncOpenFolderDB( ...
> (iii) OpenMore
> http://mxr.mozilla.org/comm-central/source/mailnews/db/msgdb/src/nsMsgDatabase.cpp#224
> 224 NS_IMETHODIMP nsMsgDBService::OpenMore( ...

Note: AsyncOpenFolderDB and OpenMore is currently used in test only.
> http://mxr.mozilla.org/comm-central/search?string=AsyncOpenFolderDB%28
> http://mxr.mozilla.org/comm-central/search?string=OpenMore%28

As seen in nsMsgDBService::OpenFolderDB code, 
> http://mxr.mozilla.org/comm-central/source/mailnews/db/msgdb/src/nsMsgDatabase.cpp#108
if msgDatabase is already cached, "notification of msgDatabase open event by someone" is not done, and because step of "msgDatabase->Open => msgDatabase->OpenInternal" is not executed by nsMsgDBService::OpenFolderDB, "NSPR log for msgDatabase open by MSGDB:5" is not written.  
> nsMsgDatabase::OpenInternal
> http://mxr.mozilla.org/comm-central/source/mailnews/db/msgdb/src/nsMsgDatabase.cpp#1215
This is applicable to "msgDatabase close".

For analysis of problem like bug 905576, problems around filer move, tracing of "when/by whom, open/close of already cached msgDatabase is requested" is needed, in addition to current MSGDB:5 log and DBopened event which is for "open with .msf file read" and "close with .msf file write".

Comment 1

[WADA:World Anti-bad-Duping Agency]

Explicit "Close of msgDatabase" by each msgDatabase opener is not needed after accessing msgDatabase? "Entity of a msgDatabase" is memory area(C++ object) and it's simply shared, and if an object which refers to the msgDataase object is destroyed, reference count is automatically reduced?
If so, event like "msgDatabase close by each msgDatabase opener" is nonsense?
If so, following events are sufficient.
- msgDatabase open is requested and CachedDb is returned to requester.
  This is currently not logged by MSGDB:5.
  Reason is perhaps; because many open requests are issued by many requester,
                     flood of MSGDB:5 log occurs.
- closeMDB() is requested by someone, then .msf is physically written.
  Similar or equivalent to "closing database" log which is currently written by MSGDB:5.

Comment 2

[Amy Gabriel]

Attachment: same problem

Thanks from dzunagoton1974.