第24回Alfresco勉強会で発表した内容です。 Alfresco上でコンテンツが作成され、削除されるまでのライフサイクルについて説明しています。

1. © 2014 aegif
第24回 Alfresco勉強会
コンテンツのライフサイクル
2014年10月15日
Jun Terashita

2. Alfresco上にコンテンツ（ノード）が作成されてから完全に消えてなくなるまで、裏側
で何が起こっているかをご説明します。
基本的には以下のBlogの翻訳になりますが、一部変わっている部分もあります。
http://www.ixxus.com/blog/2011/09/alfresco-node-lifecycle
© 2014 aegif
発表の内容
2
今回使用するバージョン
Alfresco Community 4.2.f

3. © 2014 aegif
（準備）Alfrescoのリポジトリを構成する要素
ファイルシステム（FS）
ファイル実体。デフォルトでは以下のディレクトリに保存される。
・<install_dir>/alf_data/conetntstore
データベース（DB）
コンテンツの属性情報やアソシエーション等、詳細情報が記録される。
今回の内容で関係があるのは主に以下のテーブル。
・alf_node
・alf_node_properties
・alf_content_data
・alf_content_url
Luceneインデックス（IDX）
検索用のインデックス。なくなっても上記の2つからリビルドすることが可能。
デフォルトでは以下のディレクトリに保存される（Solrを選択した場合）。
・<install_dir>/alf_data/solr/workspace/SpacesStore/index/
・<install_dir>/alf_data/solr/archive/SpacesStore/index
3

4. 5. DBのクリーニング
© 2014 aegif
ライフサイクルの全体像
4
1. コンテンツ作成
1
2. コンテンツ削除
3. ごみ箱から削除
4. FSのクリーニング
2 3 4 5
14日（default）
30日（default）
FS contentstore contentstote contentstore contentstore.deleted contentstore.deleted
DB
alf_node
alf_node.properties
alf_content_data
alf_content_url
alf_node
alf_node.properties
alf_content_data
alf_content_url
alf_node
alf_node.properties
alf_content_url
alf_node
alf_node_properties ー
（※）
IDX workspace/
SpacesStore
archive/
SpacesStore ーーー
（※）関連レコードが存在するテーブルは他にもありますが主なテーブルのみ記載しています。

5. © 2014 aegif
1. コンテンツ作成
ブラウザでAlfresco Shareを開き、適当なフォルダにコンテンツを作成する。
ノードブラウザで確認すると以下のようにファイル実体のパスやUUID、DBIDが確認できる。
5
DBID
UUID ファイル実体のパス
ストア

6. FS
<install_dir>/alf_data/conetntstore 以下に日付で区切られたフォルダが作成され、そこにリネームし
て保存される（リネーム後のファイル名とノードのUUIDは別物である点に注意）。
© 2014 aegif
1. コンテンツ作成
6

7. DB
alf_nodeテーブルから、alf_node_properties → alf_contente_data → alf_content_urlとたどり、
ファイル実体のパスまで確認できる。
alf_node
© 2014 aegif
1. コンテンツ作成
7
alf_node_properties
qname_idがcm:contentのレコード

8. © 2014 aegif
1. コンテンツ作成
8
alf_content_data
alf_content_url
ファイル実体のパス

9. IDX
Lukeでインデックスの内容を確認すると、workspace/SpacesStore/indexの中にDBIDが一致するイ
ンデックスが見つかる。
© 2014 aegif
1. コンテンツ作成
9

10. © 2014 aegif
2. コンテンツ削除
Alfresco ShareのUIから1で作成したコンテンツを削除する。
1と同様にノードブラウザから確認できる（ただし、ストアがarchiveになっている）。
10
DBID
ファイル実体のパス
UUID
ストア

11. © 2014 aegif
2. コンテンツ削除
11
FS
変化なし。同じディレクトリに存在する。

12. © 2014 aegif
2. コンテンツ削除
DB
alf_nodeテーブルのレコードが以下の2つになる。
・store_idが「archive/SpacesStore」で、type_qname_idが「cm:content」
・store_idが「workspace/SpacesStore」で、type_qname_idが「sys:deleted」
alf_node
alf_node_properties、alf_content_dataの関連レコードはidが変わる。
ただし、alf_content_urlの関連レコードはidもそのまま。
（スクリーンショットは割愛します）
12

13. © 2014 aegif
2. コンテンツ削除
IDX
archive/SpacesStore/indexの中にDBIDが一致するインデックスが見つかる（workspace/
SpacesStore/index の中には見つからない）。
13

14. © 2014 aegif
3. ごみ箱から削除
ユーザプロファイルページからごみ箱を開き、コンテンツを削除する。
※この時点でノードブラウザからは確認できなくなる。
14
FS
変化なし。同じディレクトリに存在する。

15. © 2014 aegif
3. ごみ箱から削除
DB
alf_nodeテーブルのstore_idが「archive/SpacesStore」だったレコードのtype_qname_idが
「sys:deleted」に変わる。
alf_node_propertiesにはoriginal idを保持するレコードがそれぞれ1つずつ。
alf_content_dataの関連レコードは削除される。
alf_content_urlの関連レコードはorphan_timeにごみ箱を空にした時刻が記録される。
15
alf_node
alf_content_url

16. © 2014 aegif
3. ごみ箱から削除
IDX
このタイミングでインデックスから完全に削除される。
16

17. contentStoreCleanerが定期的に実行され、alf_content_urlテーブルのorphan_timeか
ら一定期間経過しているファイル実体を、contentstoreからcontentstore.deletedに移
動する。
contentStoreCleanerのbean定義は、content-services-context.xmlを参照。
これを発火するのがcontentStoreCleanerTriggerとcontentStoreCleanerJobDetailで、scheduled-jobs-
© 2014 aegif
4. FSのクリーニング
context.xmlに定義されている。
また、実行タイミングとorphan_timeからの保持期間はrepository.propertiesで設定されている。
…
#
# Decide if content should be removed from the system immediately after being orphaned.
# Do not change this unless you have examined the impact it has on your backup procedures.
system.content.eagerOrphanCleanup=false
# The number of days to keep orphaned content in the content stores.
# This has no effect on the 'deleted' content stores, which are not automatically emptied.
system.content.orphanProtectDays=14
# The action to take when a store or stores fails to delete orphaned content
# IGNORE: Just log a warning. The binary remains and the record is expunged
# KEEP_URL: Log a warning and create a URL entry with orphan time 0. It won't be processed or removed.
system.content.deletionFailureAction=IGNORE
# The CRON expression to trigger the deletion of resources associated with orphaned content.
system.content.orphanCleanup.cronExpression=0 0 4 * * ?
…
17
repository.properties
（補足）

18. FS
ファイル実体がcontentstoreからcontentstore.deletedに移される。以降、contentstore.deletedの
中身は自由に削除してよい。
© 2014 aegif
4. FSのクリーニング
DB
alf_nodeおよびalf_node_propertiesは変化なし。
alf_content_urlから関連レコードが削除される。
IDX
「3. ごみ箱から削除」の時点でインデックスから削除されているため変化なし。
18

19. DeletedNodeCleanupWorkerが定期的に実行され、alf_nodeその他のテーブルのレコー
ドを削除する。
ここでは、alf_nodeでsys:deletedになっているレコードに対応するalf_transactionテー
ブルのcommit_time_msが一定期間経過しているものを抽出している。
（補足）
scheduled-jobs-context.xmlにnodeServiceCleanupJobDetailとnodeServiceCleanupTriggerのbean
定義があり、cronExpressionはbean定義に直接書かれている。
また、ごみ箱を空にしてからの保持期間は、repository.propertiesに設定されている。
© 2014 aegif
5. DBのクリーニング
…
# Index tracking information of a certain age is cleaned out by a scheduled job.
# Any clustered system that has been offline for longer than this period will need to be seeded
# with a more recent backup of the Lucene indexes or the indexes will have to be fully rebuilt.
# Use -1 to disable purging. This can be switched on at any stage.
index.tracking.minRecordPurgeAgeDays=30
# Unused transactions will be purged in chunks determined by commit time boundaries. 'index.tracking.purgeSize' specifies the size
# of the chunk (in ms). Default is a couple of hours.
index.tracking.purgeSize=7200000
…
19
repository.properties

20. FS
「4. FSのクリーニング」の時点でファイル実体がcontentstoreからcontentstore.deletedに移されて
いるため変化なし。
DB
alf_node、alf_node_properties、alf_transaction等から関連レコードが削除される。
© 2014 aegif
5. DBのクリーニング
IDX
「3. ごみ箱から削除」の時点でインデックスから削除されているため変化なし。
20

21. 5. DBのクリーニング
© 2014 aegif
（再掲）ライフサイクルの全体像
21
1. コンテンツ作成
1
2. コンテンツ削除
3. ごみ箱から削除
4. FSのクリーニング
2 3 4 5
14日（default）
30日（default）
FS contentstore contentstote contentstore contentstore.deleted contentstore.deleted
DB
alf_node
alf_node.properties
alf_content_data
alf_content_url
alf_node
alf_node.properties
alf_content_data
alf_content_url
alf_node
alf_node.properties
alf_content_url
alf_node
alf_node_properties ー
（※）
IDX workspace/
SpacesStore
archive/
SpacesStore ーーー
（※）関連レコードが存在するテーブルは他にもありますが主なテーブルのみ記載しています。

22. 「4. FSのクリーニング」までファイルをcontentstoreに保持する理由
・ファイルを一定期間contentstoreに保持することによって、DBとインデックスをバックアップからリ
ストアする際に、ファイルシステムのリストアをする必要がなくなるため。
・コンテンツ数が増えてくるとファイルシステムのリストアには時間がかかるため、時間の節約になる。
・当然、DBとインデックスのバックアップは（デフォルトでは）14日以内のものである必要がある。
「5. DBのクリーニング」までalf_node等のレコードを保持する理由
・インデックスの差分リビルドの際に、インデックスのバックアップ作成時点から削除されたコンテン
ツのインデックスを削除するため。
・インデックスの差分リビルドにはalf_transactionテーブルに記録されたトランザクションを参照して
おり、alf_transactionとalf_nodeが繋がっているため、レコードが消えているとインデックスの更新が
できなくなる。
・当然、インデックスのバックアップは（デフォルトでは）30日以内のものである必要がある。
© 2014 aegif
すぐに削除しない理由
22

23. © 2014 aegif
おわり