[Design of JBoss Remoting, Unified Invokers] - Re: R3 transports to implement
by david.lloyd@jboss.com
I'll start replying from the first post.
"trustin" wrote : If I remember the latest conversation with David in our IRC channel, our current timeline-less road map looks like the following overally:
|
| * 3.0 - Stable API and its R2 compatible transports (socket, RMI, servlet, bisocket)
| * 3.1 - SSH and other bells and whistles (maybe HTTP or it should go to 3.2)
|
| Are we all agreed on this overall road map? If so, we could step into more detailed tasks for each milestone.
I do agree on this; however it must be said at this point that the R2 compatibility is really not as simple as it might seem, and it might be that we end up doing a 3.0 that simply has the basic transport, 3.1 which adds some R2 types, 3.2 which adds SSH and perhaps more R2 types, etc. I think that it's most important to get a release out this September, and start time-boxing releases, even if it's not immediately usable as a complete Remoting 2 replacement.
"trustin" wrote : And... According to the recent discussion ('Hints Welcome'), David also mentioned a simple new R3 implementation for LAN use. I thought we could focus on SSH and use NUL crypto algorythm and no compression. We could also configure each request listener to require different cryptographic strength (perhaps using annotation?). WDYT?
A basic protocol implementation is necessary in order to support any SSH-based transport. Since SSH is implemented using multiplexed message-based channels, a protocol implementation is needed which can run over a message-based channel. That's what the basic protocol support is. It is not intended to be directly used in user code due to the lack of authentication, encryption, etc. But it will form the basis for the SSH transport when it is ready.
The implementation is a necessary prerequisite to 3.0 - without it, we can't know if the design is even valid.
Bear with me for a bit and I'll type up responses to the other posts as well...
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4166974#4166974
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4166974
17 years, 8 months
[Design of JBoss Transaction Services] - Re: JBAS-5801 - Locking in 2PC
by adrian@jboss.org
"jhalliday" wrote : > What we really want to do is make sure that end() blocks
| > at tx timeout until the current user operation has completed.
|
| I'd argue that's exactly what we want to avoid. One use of a tx timeout is to ensure apps don't get stuck due to e.g. slow db queries. If I issue e.g. a SELECT inside a tx and that tx has a timeout, I want it to timeout promptly, not block on the db operation. Likewise for sending or receiving messages. That's part of the reason JBossTS uses a background thread for timeouts. Sure some resource managers have explicit support for configuring timeouts on potentially long running operations, but it's not required.
|
It doesn't have to block indefinetly, the wait is configurable,
| <!-- Whether to use try locks in seconds
|
| The default is wait for a lock indefinitely
| e.g. 5 minutes
| <use-try-lock>300</use-try-lock>
| -->
| <!ELEMENT use-try-lock (#PCDATA)>
|
but the important thing is that they
don't go the wrong way around during normal operation otherwise
you end up leaking the work into the "next/no transaction" without error, e.g.
Thread 1: does sql executeUpdate();
// Here Thread 1 hits (or more accurately is just about to hit)
// the real jdbc connection, e.g. oracle code which we don't control
Thread 2: tx timeout
Thread 2: end() and rollback()
Thread 1: continues with update but now outside the transaction we initially intended
anonymous wrote :
| I'd say it's up to the resource manager's driver code to decide how to handle the situation. If it's got one thread doing a business logic operation in a tx when another thread is trying to terminate that tx, it can either block internally (I've seen the MS SQL driver do that, queuing the end to go over the same TCP/IP connection when the SELECT eventually returns) or e.g. throw an exception on the business logic thread.
|
For jdbc the correct thing to do is statement.cancel()
although that's not necessarily guaranteed to work depending upon the jdbc driver
and only for calls to the driver are that statement executes.
anonymous wrote :
| That said, one option may be to make this configurable at the JCA level. Allow e.g. -ds.xml files to contain an option for how the JCA should behave - delegate to the driver
|
We can't do that see the example above. Not because the driver
doesn't do its own locking (it probably does) but because it
might not understand the required semantics, e.g.
session.sendMessage(); // context switched before it actually does it
xaresource.rollback();
session,sendMessage() // really executes, but now outside the rolled back transaction
anonymous wrote :
| as I describe, block as you suggest,
| or even explicitly interrupt the business logic and throw an exception as some users seem to expect. The last one of course is risky, it may mess up the underlying driver.
That's the mechanism of the previous TM.
In fact, what it did besides "interrupting the thread" was effectively
destroy the connection (if the I/O was on the same thread and it was in really in I/O)
meaning the connection got closed so you couldn't leak into the next/non
transaction.
Maybe that is an alternate option?
i.e. whenever we have a tx timeout, you provide a callback to JCA
and then we close the associated connections - disallowing their use
which may not be in a well defined state.
We could do this on a per connection-factory case depending upon
how well we know the underlying thirdparty code handles asynch rollbacks
concurrently with normal requests.
But my criticism of this is that the connection.close() is still
racing with the normal operation outside the intended transaction
so it could still complete before we close the connection to "cancel it".
Of course, if we closed the connections before the now unnecessary rollback()
then this wouldn't be a problem. ;-)
BACK ON TOPIC:
You didn't answer my question (even though I think I already know the answer :-)
which is that we only need to protect the end() invoked by the TM
to avoid the race, not the XAResource commit/rollback.
Which would mean the transaction interleaving problem of 5801 is easier to solve.
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4166952#4166952
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4166952
17 years, 8 months