Hi,

You are not actually creating a true Singleton at the session level. The reason two objects appear in the database is because your microflow logic is not atomic, and Mendix likely executes the microflow twice before the first commit completes.

This causes a classic race condition.

Why This Happens in Mendix

Mendix does not have built-in Singleton support for entities (this is an acknowledged limitation in the platform). A Singleton pattern in Mendix is implemented as a convention, not enforced by the platform itself.

In your flow:

1. You first Retrieve NotificationCount
2. If it doesn’t exist, you then Create NotificationCount
3. You associate it with Session and commit

But if the microflow is triggered more than once (for example by two calls, page load + nanoflow, or overlapping transactions), the first retrieve has not yet committed an object, so both executions see “nothing found” and both create a new object.

This results in two objects in the database — even though you expected only one.

This is not a bug — it’s a race condition.

Correct Implementation Pattern

Step 1: Use a Proper Retrieve XPath

You must retrieve using a strict session constraint, not a plain object retrieve.

Example:

Retrieve NotificationCount where
NotificationCount_Session = '[%CurrentSession%]'

This ensures you are checking based on the exact session relationship.

If you do not constrain based on session, you might retrieve global object or none, leading to duplicates.

Step 2: Centralize Logic in One Microflow

Make one dedicated microflow:

GetOrCreateNotificationCountForSession()

Inside:

1. Retrieve NotificationCount by session
2. If exists → return it
3. If not → create, associate with session, commit → return

This makes sure only one check-create sequence runs.

Do not spread across multiple flows.

Step 3: Ensure Single Execution

Call this microflow only once per session event (e.g., on page load).

If you call it from multiple places, Mendix might execute it in parallel before commit finishes.

If you have UI triggers (nanoflows) that also call this microflow, wrap them such that they do not execute the same logic twice.

Use Before Commit or Unique Constraint

For enterprise stability:

• Add a unique index on a SessionId (string) attribute
• Use a Before Create Event to throw an error if already exists

Example:

Before Create
If count(NotificationCount where session = THIS.session) > 0
   Rollback

This guards against duplicates even under concurrency.

Alternative (Session-Scoped Only)

If this object really only belongs to session and you do not need persistence beyond the session, you should consider using a non-persistent entity for NotificationCounter.

Non-persistent entities are stored in memory for the session lifecycle and are never written to the database, eliminating duplicates entirely.

• Mendix does not enforce singleton on DB entities automatically.
• Your flow runs twice before commit — causing duplicates
• Use strict session-based retrieve
• Consolidate logic into one microflow
• Optionally add unique constraint / before-create guard
• Or use non-persistent entity for session-scoped data

Boda,

I don't now when this microflow is called, but it seems like it is being called more than once and the two microflow instances are running close enough together that the first microflow instance is not complete before the second one runs. To prevent this, try setting the microflow to disallow concurrent execution:

Let me know if that resolves the issue.

Mike