-
Notifications
You must be signed in to change notification settings - Fork 1
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.
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
Ability to use the transactional session inside a send-only endpoint #96
Comments
I'm looking forward using this package and get rid of complicated code written to get consistency between NServiceBus message publishing and database updates in our ASP.NET Core applications. However, it surprises me that it is not possible to use this package in a send-only endpoint yet. When reading the documentation and blog posts it sounds like just the scenario you're aiming for. Are there any estimates on when send-only endpoints will be supported? |
@pardahlman no estimates currently. To make sure we understand you use case better -- is there anything that would prevent you from using full NServiceBus endpoint in the web application? |
Thanks for getting back to me 🙏 No, there is no technical limitation, rather a logical one: these endpoint does not consume messages and is therefor correctly configured as send-only endpoints. Making them full endpoints would slow down startup slightly and also create unwanted topology in our transport. |
OK, I understand. The current limitation is related to the fact, that the transactional session uses a message send locally to commit or abort the transaction. This special control message plays the role which is fulfilled by a database polling background process in other outbox implementation. We decided to use the message because the polling mechanism causes serval issue in any non-trivial production deployment, especially with partition data stores:
Thanks for your feedback, we are definitely going to take it into account when releasing new versions. We will again analyze the consequences of introducing (optional) polling or having a dedicated endpoint processing the control messages so that the web frontend endpoints can stay send-only. |
Please allow me to add a bit more context here too. We have also discussed that we could allow sending the control message to a dedicated "backend" endpoint. During the initial design discussions, we have discussed the concept of ownership of endpoint data and how that "backend" endpoint would fit it. We brought up the argument that many times API endpoints that are send-only have some sort of a backend endpoint already and that one has to be treated as part of the "same service". So, ownership of the outbox data should not be too much of a problem. Yet because we didn't entirely settle on a viable approach on these discussions, we have decided to "scope it out" from the initial release. I'm mentioning this because we don't necessarily need to introduce polling. Sending the control message to somewhere else is totally feasible too. |
Core 8.1 will contain a backdoor setting to force the outbox to enable send-only endpoints to enable this scenario to be implemented. See Particular/NServiceBus#6750 for details |
Now that the backdoor setting that allows this to be implemented is done, do you guys have a planned milestone to implement the feature in the near future? |
Hi @hugovlc this will likely be picked up by our recurring enhancement release process but I can't give you a timeline at this stage. How does the timeline look on your end? Are you blocked by this not being available? |
@andreasohlund Yes because we recently changed transport to SqlServer transport and our business data is in oracle. TransactionScope is not an option. |
It really cool feature. I'm looking forward for it implementation. |
There's nothing new to report since this last update. We are tracking this in our backlog, but we have not started the implementation yet. |
FWIW my team is waiting on this feature before we can stop relying on TransactionScope. This is holding us back from support on some platforms. |
Hi all, I wanted to update you on where we stand on this.
|
Hi, any update on this topic and a possible timeline? |
@daenumueller the work is scheduled and will start shortly or so so my best guestimate is that it will be ready late Q1 As mentioned above just reach out to us if you need to arrange a commercial workaround until the work is complete |
Is there any status update on this? It's been a while since the end of Q1 |
@ThreePinkApples sorry for the delay, we had to adjust our priorities but the work is now set to begin within 1-2 months so my best guestimate as of now is late Q4 this year Are you in any way blocked by this? |
@andreasohlund No, not really blocked by this, more a nice to have for us in some cases. Just wanted to know whether it had been abandoned or not |
Got it, thanks for taking the time to reach out. We'll keep you posted here as we start working! |
Currently, the transactional session requires the endpoint using the transactional session to be an endpoint with a queue. Send-only endpoints are not supported. One of the restrictions is given by the Core since the outbox seam prevents it being used in send-only endpoints.
By lifting these constraints (potentially with a settings bypass) we could separate the endpoint configuration into two parts:
The text was updated successfully, but these errors were encountered: