Many legacy Communication servers can employ file servers for account data storage. Since those servers are usually implemented as multi-process systems (under Unix), they use the same synchronization methods in both single-server and multi-server environments, such as file locks implemented on the Operating System/File System level.
This method has the following problems:
In the attempt to decrease the negative effect of file-locking, some legacy Messaging servers support the MailDir Mailbox format only (one file per message), and they rely on the "atomic" nature of file directory operations (rather than on file-level locks). This approach theoretically can solve some of the outlined problems (in real-life implementations it hardly solves any), but it results in wasting most of the file server storage, and overloads the file server internal filesystem tables. The performance of File Servers severely declines when an application uses many smaller files instead of few larger files.
While simple clustering based on Operating System/File System multi-access capabilities works fine for Web servers (where the data is not modified too often), it does not work well for Messaging servers where the data modification traffic is almost the same as the data retrieval traffic.
Simple Clustering does not provide any additional value (like Single Service Image), so administering a 30-Server cluster is even more difficult than administering 30 independent Servers.
The CommuniGate Pro software supports the Legacy INBOX feature, so a file-based clustering can be implemented with the CommuniGate Pro, too. But because of the problems outlined above, it is highly recommended to avoid this type of solutions and use the real CommuniGate Pro Dynamic Cluster instead.