Database binary storage space leak?

[zcc39r]

If I put a file into JDBC-backed repository (e.g. via WebDAV interface) I can see that two rows were added to MODESHAPE_REPOSITORY table as well as to CONTENT_STORE table. When I delete this file, the number of rows in MODESHAPE_REPOSITORY reduces by two, but not in CONTENT_STORE - rows added at file creation remains untouched.

Will be that rows at CONTENT_STORE reclaimed sometime in the future or it's simply a storage space leak?

[hchiorean]

Binary storage and repository storage are independent of each other.

The data from the binary store (i.e. binary values) is *eventually reclaimed* by a GC thread. The ModeShape documentation (Binary values - ModeShape 5 - Project Documentation Editor explains this.

[zcc39r]

The ModeShape documentation (Binary values) explains this.

The repository periodically runs a multi-phase garbage collection process to identify those binaries that are no longer referenced by repository content. When such binaries are discovered, the repository calls the BinaryStore's markAsUnused(...) method.

What is the algorithm of such a discovery? I can see that removeValuesUnusedLongerThan() is called periodically, but not markAsUnused().

[hchiorean]

Binaries are marked as used and unused via *a* transaction synchronizer - modeshape/WritableSessionCache.java at master · ModeShape/modeshape · GitHub

That logic of detecting which binaries are used or not takes places during #session.save() but the actual changes are persisted only if a transaction is committed. ModeShape uses internally 1 synchronizer per transaction, but that synchronizer contains multiple "functions"  (in a list) because the order of operations is important.

[zcc39r]

Thank you, Horia, for explanation!

So, I guess, the wording mentioned above should be changed slightly in documentation since there is no periodically running unused binary discovery phase. And periodically running GC process is single-phased.