Skip to content

docs: limitless docs #914

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom
Open
wants to merge 2 commits into
base: main
Choose a base branch
from
Open

docs: limitless docs #914

wants to merge 2 commits into from
+92 −10

Conversation

JuanLeee
Copy link
Collaborator

@JuanLeee JuanLeee commented Jul 8, 2025

Description

Adding documents for limitless plugin support.

By submitting this pull request, I confirm that my contribution is made under the terms of the Apache 2.0 license.

karenc-bq
karenc-bq reviewed Jul 8, 2025
View reviewed changes
@JuanLeee JuanLeee force-pushed the docs/limitless branch 2 times, most recently from bd98716 to e1b4ae2 Compare July 10, 2025 17:38
aaron-congo
aaron-congo reviewed Jul 15, 2025
View reviewed changes
aaron-congo
aaron-congo reviewed Jul 17, 2025
View reviewed changes
docs/using-the-python-driver/UsingThePythonDriver.md
| [Aurora Connection Tracker Plugin](./using-plugins/UsingTheAuroraConnectionTrackerPlugin.md) | `aurora_connection_tracker` | Aurora | Tracks all the opened connections. In the event of a cluster failover, the plugin will close all the impacted connections to the host. This plugin is enabled by default. | None |
| [Read Write Splitting Plugin](./using-plugins/UsingTheReadWriteSplittingPlugin.md) | `read_write_splitting` | Aurora | Enables read write splitting functionality where users can switch between database reader and writer instances. | None |
| [Fastest Response Strategy Plugin](./using-plugins/UsingTheFastestResponseStrategyPlugin.md) | `fastest_response_strategy` | Aurora | A host selection strategy plugin that uses a host monitoring service to monitor each reader host's response time and choose the host with the fastest response. | None |
| [Limitless Connection Plugin](using-plugins/UsingTheLimitlessPlugin.md) | `limitless` | Aurora | Enables client-side load-balancing of Transaction Routers on Amazon Aurora Limitless Databases. | None |
Copy link
Contributor

Choose a reason for hiding this comment

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

Suggested change
| [Limitless Connection Plugin](using-plugins/UsingTheLimitlessPlugin.md) | `limitless` | Aurora | Enables client-side load-balancing of Transaction Routers on Amazon Aurora Limitless Databases. | None |
| [Limitless Plugin](using-plugins/UsingTheLimitlessPlugin.md) | `limitless` | Aurora | Enables client-side load-balancing of Transaction Routers on Amazon Aurora Limitless Databases. | None |

docs/using-the-python-driver/using-plugins/UsingTheLimitlessPlugin.md
| `limitless_transaction_router_monitor_disposal_time_ms` | Integer | No | This property is the time in milliseconds that a Limitlesstransaction router monitor can remain unused before it is disposed. This ensures that in periods of long inactivity, the database isn't being needlessly polled and the resources associated with the monitor can be cleaned up. Note that when a new connection is created, a new Limitlesstransaction router monitor will also be created to resume polling the database. | `600000` | `300000` |
| `limitless_max_retries_ms` | Integer | No | This property is the max number of retries the Limitless Plugin will attempt when failing to connect to the database. During these retries, the plugin will attempt to connect to the least loaded transaction router that is available. If the max number of connection retries is exceeded, then the plugin will throw a `AwsWrapperError`. In this scenario, it is likely that the database is in an unhealthy state, and the `AwsWrapperError` should be caught and handled by your application. | `5` | `13` |
| `limitless_wait_for_transaction_router_info` | Boolean | No | In scenarios such as application start-up, the cache of available transaction routers and their load metric info will be empty. If `limitlessWaitForTransactionRouterInfo` is set to `true`, the plugin will wait until the cache is populated before selecting a transaction router and connecting to it. This may be beneficial for applications that create a large number of connections on start-up, since these connections will be load-balanced. <br><br>Alternatively, if this property set to `false` and the cache is empty, the plugin will not wait for the cache to be populated and default to using the DB Shard Group endpoint to connect to until the cache is populated. This will result in connections being routed to a transaction router via Route 53 until the cache is populated. This may be beneficial for applications that prioritize quicker start-up times at the expense of some early connections not being load-balanced by the Limitless Plugin. | True | False |
| `limitless_get_transaction_router_max_retries` | Integer | No | This property is the max number of times the Limitless Connection Plugin will retry fetching available transaction routers and their load metrics. These retries will occur if the fetched transaction router information is `None` or empty. If this max is reached, a `SQLException` will be thrown. In this scenario, it is likely that the database is in an unhealthy state, and the thrown `SQLException` should be caught and handled by your application. <br><br>If your application prioritizes failing fast, then consider a lower value for this property. However, if your application prioritizes durability, then consider a higher value. | `5` | `10` |
Copy link
Contributor

Choose a reason for hiding this comment

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

Suggested change
| `limitless_get_transaction_router_max_retries` | Integer | No | This property is the max number of times the Limitless Connection Plugin will retry fetching available transaction routers and their load metrics. These retries will occur if the fetched transaction router information is `None` or empty. If this max is reached, a `SQLException` will be thrown. In this scenario, it is likely that the database is in an unhealthy state, and the thrown `SQLException` should be caught and handled by your application. <br><br>If your application prioritizes failing fast, then consider a lower value for this property. However, if your application prioritizes durability, then consider a higher value. | `5` | `10` |
| `limitless_get_transaction_router_max_retries` | Integer | No | This property is the max number of times the Limitless Plugin will retry fetching available transaction routers and their load metrics. These retries will occur if the fetched transaction router information is `None` or empty. If this max is reached, a `AwsWrapperError` will be thrown. In this scenario, it is likely that the database is in an unhealthy state, and the thrown `AwsWrapperError` should be caught and handled by your application. <br><br>If your application prioritizes failing fast, then consider a lower value for this property. However, if your application prioritizes durability, then consider a higher value. | `5` | `10` |

docs/using-the-python-driver/using-plugins/UsingTheLimitlessPlugin.md
| `limitless_transaction_router_monitor_interval_ms` | Integer | No | This property is the interval in milliseconds, that the plugin polls the database for available transaction routers and their load metrics. A lower value will increase the frequency of polling, and a higher value will decrease the frequency of polling. <br><br>Note that there will always be a delay between when the database updates its load metric info and when the Limitless Plugin polls for it. If your Limitlessdatabase experiences fluctuating load between transaction routers, you may want to consider lowering `limitlessTransactionRouterMonitorIntervalMs` to reduce this delay and ensure the Limitless Plugin load balancing has fresher info to work with. <br><br>The default value of this property is 7.5 seconds. This is half the interval that the database updates its load metric metadata. This value was chosen as a compromise between having fresher load metric info, but also being conscious of the associated overhead. | `7500` | `30000` |
| `limitless_transaction_router_monitor_disposal_time_ms` | Integer | No | This property is the time in milliseconds that a Limitlesstransaction router monitor can remain unused before it is disposed. This ensures that in periods of long inactivity, the database isn't being needlessly polled and the resources associated with the monitor can be cleaned up. Note that when a new connection is created, a new Limitlesstransaction router monitor will also be created to resume polling the database. | `600000` | `300000` |
| `limitless_max_retries_ms` | Integer | No | This property is the max number of retries the Limitless Plugin will attempt when failing to connect to the database. During these retries, the plugin will attempt to connect to the least loaded transaction router that is available. If the max number of connection retries is exceeded, then the plugin will throw a `AwsWrapperError`. In this scenario, it is likely that the database is in an unhealthy state, and the `AwsWrapperError` should be caught and handled by your application. | `5` | `13` |
| `limitless_wait_for_transaction_router_info` | Boolean | No | In scenarios such as application start-up, the cache of available transaction routers and their load metric info will be empty. If `limitlessWaitForTransactionRouterInfo` is set to `true`, the plugin will wait until the cache is populated before selecting a transaction router and connecting to it. This may be beneficial for applications that create a large number of connections on start-up, since these connections will be load-balanced. <br><br>Alternatively, if this property set to `false` and the cache is empty, the plugin will not wait for the cache to be populated and default to using the DB Shard Group endpoint to connect to until the cache is populated. This will result in connections being routed to a transaction router via Route 53 until the cache is populated. This may be beneficial for applications that prioritize quicker start-up times at the expense of some early connections not being load-balanced by the Limitless Plugin. | True | False |
Copy link
Contributor

Choose a reason for hiding this comment

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

Suggested change
| `limitless_wait_for_transaction_router_info` | Boolean | No | In scenarios such as application start-up, the cache of available transaction routers and their load metric info will be empty. If `limitlessWaitForTransactionRouterInfo` is set to `true`, the plugin will wait until the cache is populated before selecting a transaction router and connecting to it. This may be beneficial for applications that create a large number of connections on start-up, since these connections will be load-balanced. <br><br>Alternatively, if this property set to `false` and the cache is empty, the plugin will not wait for the cache to be populated and default to using the DB Shard Group endpoint to connect to until the cache is populated. This will result in connections being routed to a transaction router via Route 53 until the cache is populated. This may be beneficial for applications that prioritize quicker start-up times at the expense of some early connections not being load-balanced by the Limitless Plugin. | True | False |
| `limitless_wait_for_transaction_router_info` | Boolean | No | In scenarios such as application start-up, the cache of available transaction routers and their load metric info will be empty. If `limitlessWaitForTransactionRouterInfo` is set to `True`, the plugin will wait until the cache is populated before selecting a transaction router and connecting to it. This may be beneficial for applications that create a large number of connections on start-up, since these connections will be load-balanced. <br><br>Alternatively, if this property set to `False` and the cache is empty, the plugin will not wait for the cache to be populated and default to using the DB Shard Group endpoint to connect to until the cache is populated. This will result in connections being routed to a transaction router via Route 53 until the cache is populated. This may be beneficial for applications that prioritize quicker start-up times at the expense of some early connections not being load-balanced by the Limitless Plugin. | True | False |

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Reviewers

@aaron-congo aaron-congo aaron-congo left review comments

@karenc-bq karenc-bq karenc-bq approved these changes

Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

Successfully merging this pull request may close these issues.
3 participants
@JuanLeee @karenc-bq @aaron-congo