You can repair a Singleton-class data error by finding the duplicate persisted objects in the MDriven OCL Debugger, deleting the extras, and saving the corrected database state.

What the error means

If MDriven reports an error such as:

The Singleton class SysSingleton has multiple instances

more than one object exists for a class that is marked as a Singleton. A Singleton class must have only one instance.

This is a data problem in the persistence store. It does not mean that more than one user, browser window, or running application instance is viewing the application.

When this can happen

One known case occurs when you migrate data to MDrivenServer persistence. Migration can create a Singleton object from the source data even when the destination already contains one. For example, migrating data can leave two SysSingleton objects in the MDrivenServer database; starting Turnkey against that database then reports the error.

Fix duplicate Singleton objects

Use the MDriven OCL Debugger against the same persistence store and database that reports the error.

1. In MDriven Designer, start the system with the persistence configuration that points to the affected database.
2. Open the debugger.
3. In the Classes picker, select the class named in the error. For example, select SysSingleton for the error shown above.
4. Click Select 50 and then execute the selection with Execute (F5). Verify that the result contains multiple objects.
5. Click Seeker, then click Search to show the selected objects in a view where you can delete them.
6. Select an extra object and click Delete Selected. Repeat until one object remains.
7. Return to the main debugger form and click Save to persist the deletion.
8. Refresh or restart the application that showed the error. For a browser-based application, press F5.

Alternative: query all instances with OCL

You can also enter an OCL expression for the affected class:

SysSingleton.allInstances

Replace SysSingleton with the class name from the error. allInstances returns a Set of existing instances of that classifier, including instances of inherited classifiers. Use the result to verify the duplicate objects before opening Seeker and deleting the extras.

For example, if the expression returns two objects, delete one and save. Do not use a Bag count as proof that duplicate objects exist: a Bag can contain the same object more than once as the result of an operation, while allInstances returns a Set.

How many objects to keep

Normally, delete duplicate objects and leave one instance of the Singleton class.

You can also leave zero instances. When the application first requests the Singleton through the oclSingleton operator, that operator recreates it. This is useful when neither duplicate instance contains data you need to retain.

Result after cleanup	Effect
One Singleton object remains	The existing Singleton state is retained.
Zero Singleton objects remain	oclSingleton creates an instance when it is first requested.

Example: SysSingleton after migration

After migrating XML data into an MDrivenServer database, Turnkey may fail to start with The Singleton class SysSingleton has multiple instances.

1. Start the system using MDrivenServer persistence and open the debugger.
2. Select SysSingleton in the Classes picker.
3. Run Select 50 with Execute (F5).
4. Open Seeker and click Search.
5. Delete one of the two SysSingleton objects.
6. Click Save in the debugger.
7. Return to Turnkey and refresh the failed page.

For the full migration exercise and its surrounding setup, see Training:Bootcamp:Chapter 14.

See also

• Documentation:OCLOperators allInstances
• Documentation:Set vs bag
• Training:Bootcamp:Chapter 14
• Documentation:MultiTenantPrefix
• Documentation:Scaling MDrivenServer for multiple reasons