[dmlloyd]

Paul Robinson wrote:

David,

Yes, I was assuming that this would lie underneath extensions. I just needed some place to do the prototype and I felt that deploying an application would be too high up the stack.

Do you agree that this approach is adequate for you to develop a solution for Transactional MSC?

Yes, we can get started with this.

Paul Robinson wrote:

Also, does it look like it would be adequate for how you are planning on implementing the "embeded use of the server infrastructure" feature?

No, in order to embed we have to be able to dynamically create instances that do not have global state.  So (assuming our initial prototype works out) that issue will have to be resolved before we go too far with this.

Paul Robinson wrote:

If so, I think we can defer the discussion around removing global state, until we are further down the implementation path of Transactional MSC.

If so, I think the next steps are for me to update my prototype to create a minimal configuration of ArjunaCore that meets your requirements, as documented on this page so far. For example, disabling stats, disabling the recovery manager's network port, etc.

Should we also document, in more detail, your plan on how you intend to use ArjunaCore? This would probably make it easier for us to provide feedback and to also make sure Narayana is providing everything you need.

This would probably be the next discussion to have.  At the NCL meeting we chatted and brainstormed some ideas that I would like to make more concrete.  Though it might be more efficient to do this intereactively (e.g. IRC, or hangout, or phone), and gather the notes afterwards?

[paul.robinson]

David,

Paul Robinson wrote:

Also, does it look like it would be adequate for how you are planning on implementing the "embeded use of the server infrastructure" feature?

No, in order to embed we have to be able to dynamically create instances that do not have global state.  So (assuming our initial prototype works out) that issue will have to be resolved before we go too far with this.

OK, in that case I don't understand your requirement yet. However, I think we can discuss that in more detail later.

Tom and I have discussed the idea of removing global state from ArjunaCore and it looks achievable. We don't envisage a scenario where you wed yourself to ArjunaCore and then we say that we can't remove the shared state. Mark also didn't seem to think this would be a problem, although take that as idle gossip until he confirms or denys ;-)

As an aside, it would be handy to know what the roadmap is around multi-tenancy in WildFly. I'd assume removing global state in ArjunaCore was a starting point for Narayana to support multi-tenancy. I'd expect that we'd need support from the whole AS before we can truly support multi-tenancy.

Paul Robinson wrote:

If so, I think we can defer the discussion around removing global state, until we are further down the implementation path of Transactional MSC.

If so, I think the next steps are for me to update my prototype to create a minimal configuration of ArjunaCore that meets your requirements, as documented on this page so far. For example, disabling stats, disabling the recovery manager's network port, etc.

Should we also document, in more detail, your plan on how you intend to use ArjunaCore? This would probably make it easier for us to provide feedback and to also make sure Narayana is providing everything you need.

This would probably be the next discussion to have.  At the NCL meeting we chatted and brainstormed some ideas that I would like to make more concrete.  Though it might be more efficient to do this intereactively (e.g. IRC, or hangout, or phone), and gather the notes afterwards?

Google Hangout is usually our prefered medium for remote collaboration. I'll take this offline, so as not to pollute this discussion.

[marklittle]

"Tom and I have discussed the idea of removing global state from ArjunaCore and it looks achievable. We don't envisage a scenario where you wed yourself to ArjunaCore and then we say that we can't remove the shared state. Mark also didn't seem to think this would be a problem, although take that as idle gossip until he confirms or denys ;-)"

It shouldn't be a problem, but I'd have to look through the code to be sure. It's not going to be as simple as changes isolated to ArjunaCore though, because potentially everything that layers on it may be impacted by the changes, cf statistics gathering. However, any changes should not be visible through interfaces and classes directly.

[marklittle]

The prototype code should remain outside of ArjunaCore, since the latter is deliberately distribution agnostic.

Also you mention that isolation is essentially read-dirty (see reference to sockets). Do we have to worry about cascading aborts then?

[paul.robinson]

Mark Little wrote:

The prototype code should remain outside of ArjunaCore, since the latter is deliberately distribution agnostic.

Agreed.

Also you mention that isolation is essentially read-dirty (see reference to sockets). Do we have to worry about cascading aborts then?

I think this is something for the RM to handle (i.e. in the TxMSC code). To expand on what you mention and to check I understand the problem you are referring to, this is the issue that could need addressing:

1. Service 1 begins TX1 and opens a socket.

2. Service 2 begins TX2 and votes commit on the understanding that the socket is available

3. TX1 rollsback for some reason.

4. Service 2 is in an undesirable state as it is now operating without the required socket.

[marklittle]

This is not something the RM can handle by itself: it is an inevitable consequence of allowing the state of an inflight transaction to be seen by another party and for that party to then make a decision based upon that information. It's called cascading abort/roll back for a reason because you could potentially end up chasing any number of other transactions through the system to try to get them all to rollback if the original transaction does have to abort. And of course that assumes those subsequent transactions have not themselves either committed or allowed other parties to see dirty data that they have generated.

Something like the sockets example may well be a hit that we have to take. It's like using transactions to control the output of money from a cashpoint: once the money is dispensed there's no way you can get it back even if the transaction rolls back.

[dmlloyd]

Sockets might not be a great example since I have a specific solution to that particular issue.  It basically works like this (note that this is deliberately oversimplified just to illustrate the point; in reality the locking will have to be somewhat more sophisticated to account for binding vs unbinding transactions):

Since the bindings are "handed off" between transactions that are interested in them using a lock per binding, they more or less become a transactional resource.

[marklittle]

I assume the lock is maintained by the transaction and only released at commit/rollback?

Another approach would be to pass over the socket during the 2nd phase of the commit. There's still a window of vulnerability (e.g., a crash happens before the socket gets handed over but after the log is written, causing recovery to come into play), but it is greatly reduced.

[dmlloyd]

Yeah the lock is managed by the transaction.

An interesting aspect of socket binding in particular is that if a crash happens, the socket binding is forgotten anyway due to process termination.  Due to the peculiarities of the requirements for management, it is in fact possible to configure a conflicting binding in "management" mode (a sort of offline mode where the configuration database can be edited without affecting run time state) as long as there isn't a conflict within the configuration itself (which is a basic uniqueness constraint); due to the fact that the container is offline at this time, the OS is never invoked to try the physical binding so that entire process is skipped.  The sum of all of this is that socket binding in particular should be no more crash-averse than a plain management DB update (because once you crash the process owning the socket binding, that's all you have left anyway).

It is still my hope that we can simplify the recovery process by taking advantage of the fact that the only persistent participants will be the ones that update configuration databases; everything else goes away when its process dies.

[marklittle]

Sounds like Socket management could be done through a recoverable resource instead of a persistent/durable resource. The distinction is that in the former case there's no recovery necessary.

[dmlloyd]

Ah, I was not aware of the distinction.  That's good to know - the MSC task container and the non-persistent server configuration DBs would also fall into this category.  How does this affect our AbstractRecord implementation?

[tomjenkinson]

If I am following the question correctly ("how to handle none-persistent resource types?") the example that Paul has provided for the subordinate transactions would still hold true I would think (unless you had purely none-persistent resources on the remote side).

None-persistent AbstractRecords that are enlisted with transactions (based from the ConfigService example) would need altering to not override doSave() (and not pack/unpack in save_state/restore_state).

[paul.robinson]

Tom Jenkinson wrote:

If I am following the question correctly ("how to handle none-persistent resource types?") the example that Paul has provided for the subordinate transactions would still hold true I would think (unless you had purely none-persistent resources on the remote side).

None-persistent AbstractRecords that are enlisted with transactions (based from the ConfigService example) would need altering to not override doSave() (and not pack/unpack in save_state/restore_state).

I agree.

I could add this type of record to the prototype if you (David) think it would help. However, I think it really is as straight-forward as Tom suggests, so you can probably imagine it quite easily.

[marklittle]

Return false from doSave.

[marklittle]

save_state/restore_state won't be called if doSave returns false.