Skip to content

Comments

Add support to batch insert messages#7

Merged
MohamedSabthar merged 11 commits intoballerina-platform:mainfrom
MohamedSabthar:put-all
Jan 6, 2026
Merged

Add support to batch insert messages#7
MohamedSabthar merged 11 commits intoballerina-platform:mainfrom
MohamedSabthar:put-all

Conversation

@MohamedSabthar
Copy link
Member

@MohamedSabthar MohamedSabthar commented Dec 12, 2025

Purpose

$subject

Examples

Related to: wso2/product-ballerina-integrator#2081, wso2/product-ballerina-integrator#2110

Checklist

  • Linked to an issue
  • Added tests
  • Updated the spec
  • Checked native-image compatibility

@MohamedSabthar MohamedSabthar dismissed SasinduDilshara’s stale review December 22, 2025 06:47

The merge-base changed after approval.

Copy link
Member

@MaryamZi MaryamZi left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Some comments from the other PR apply here too.

return error("Failed to load message count from the database: " + messageCount.message(), messageCount);
}

if messageCount > self.maxMessagesPerKey {
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Don't we need this still?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We do't need to do that. It should be handled by the caller as discussed previously with @shafreenAnfar and @SasinduDilshara.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

For updates, yes. But this gets called during a get too, right? I'm not sure we can expect users to do this check for gets also.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

if updates are already handled by the user, that guarantees the memory will always have a message count below the configured size. I do not think we need to handle this in get.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Won't happen for the first get that happens if no update has happened, right?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

As discussed offline with @MaryamZi, there can be cases where a memory instance is created with a specific size configuration, for example 10, and updates are persisted accordingly, so the database contains 10 entries. Later, if the user code is changed to use a smaller size, the database may still hold more entries than the new limit, which could result in an error.

Since this is a very rare scenario, we are currently removing the size check to reduce database calls.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

When the cache is used, there'll be less database calls anyway, so one here would be okay IMO.

@MohamedSabthar MohamedSabthar merged commit 22b83a3 into ballerina-platform:main Jan 6, 2026
2 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants