While somewhat ancient, I use what is below to crawl an EAR and find which repositories are configured to actually use the ServerLockManager in ATG.
for f in $(find . -name "*.jar" -type f ); do
for x in $(jar -tvf $f | grep xml$ | awk '{print $NF}'); do
unzip -c $f $x | grep 'cache-mode="locked"';
if [ $? -eq 0 ]; then
echo $f $x;
fi;
done;
done
This will show both the item-descriptor (if on the same line as the cache-mode directive), and the name of the JAR with the repository definition file.
I found the following when I ran what is above…
display-property="invoiceNumber" cache-mode="locked">
display-property="address1" cache-mode="locked">
./atg_bootstrap.war/WEB-INF/ATG-INF/DCS/config/config.jar atg/commerce/invoice/invoiceRepository.xml
./atg_bootstrap.war/WEB-INF/ATG-INF/DAF/Search/Routing/config/config.jar atg/search/routing/repository/SearchConfigurationRepository.xml
./atg_bootstrap.war/WEB-INF/ATG-INF/DAF/Search/Index/config/config.jar atg/search/repository/IncrementalItemQueue.xml
./atg_bootstrap.war/WEB-INF/ATG-INF/DAF/Deployment/liveconfig/config.jar atg/deployment/deployment.xml
The ServerLockManager is only ever used in a repository call. Recall that an ATG repository is simply an Object Relational Mapping framework. An item descriptor represents either a single table, or multiple tables in the case of a join. Regardless, if the data is something that should only be updated, or perhaps even read, by a single session at a time, the access to the data can be managed via a lock manager. There are multiple cache modes for an item descriptor. The only time a lock manager is used is when the cache mode is either locked or distributed.
Out of the box, very few repositories require a ServerLockManager.
The other caching modes, simple, distributed tcp, distributed jms, and distributed hybrid, do not require a ServerLockManager.
Distributed TCP uses the das_gsa_subscriber table to store item descriptors and servers that have an interest in knowing when a repository item from that item descriptor is changed. When an item is invalidated by any server configured for distributed tcp caching, the server that initiated the change looks up all servers that have an interest and sends a message to each over a TCP socket. Application delivery is not guaranteed in distributed TCP caching. Why don’t they use UDP then?
Distributed JMS persists the invalidation messages in the database. Use this when a given instance *must* invalidate the repository item to be invalidated.
Distributed hybrid caching stores all items to be cached for the given repository in a GSA cache server. All the instance invalidating the repository item must do is send a message to this server. This server then sends invalidation messages to only those servers that have the item cached. This is good as it greatly reduces network traffic, just ensure you have enough memory in the cache server to store everything.
Additional notes on the ServerLockManager are shown below.
The architecture is as follows:
A repository configured to point to ClientLockManager
ClientLockManager points to ServerLockManager
The ClientLockManager opens a single socket to the ServerLockManager, and manages messages and waking up clients when locks are available.
Troubleshooting the ServerLockManager
enable debug
TCPDUMP – If the ClientLockManager can talk to the ServerLockManager, you should see a message come across on port 9010. You should also see the repository item Id (the primary key) of the item (row) being locked. Even if it can’t obtain the lock, you will see the network request as the ServerLockManager will add it to a waiting list. If you don’t see the request, troubleshoot the network and the ClientLockManager.