"[EMAIL PROTECTED]" wrote : ResourceAdapter.getXAResources is for message inflow recovery, | see JCA1.5 Section 12.5.2 | The activation specs must be persisted for recovery purposes. |
We really don't have any component that uses inflow yet do we? I'll do this one on the second iteration of the recovery mechanism. anonymous wrote : | For outbound it needs to do ManagedConnection.getXAResource(). | For the Subject problem see the special case mentioned in JCA1.5 Section 6.5.3.5 | This looks insecure to me (and probably not supported by some XAResources) | so we may need to add configuration for a recovery user/password where | this cannot be determined from the JCA config. | Yes, I already read that section...What Subject are you suppoed to pass in? It is the ConnectionRequestInfo that is supposed to be null. anonymous wrote : | The fundamental problem is that the transaction manager needs to get the list | of ResourceAdapters/ManagedConnectionFactorys to perform recovery. | But this cannot be done using a <depends-list> because the ResourceAdapter | needs a reference to the transaction manager before it can start (chicken and egg). | 1) For the XATerminator - RARs could try to use this during start() | 2) For the tx-connection-factory/tx datasources - not strictly necessary since we | don't need the connection manager or pool for recovery | | So what is required is that there be a separate recovery MBean that has a | <depends-list> of the ResourceAdapters. | This will allow the following startup ordering: | 1) Transaction manager | 2) Resource Adapters | 3) Recovery manager | | I don't think this needs to be that complicated. If we force/require all ResourceAdapters and ManagedConnectionFactory's to have a specific ObjectName attribute then we can do an MBean query on the MBeanServer to find these MBeans. >From what you're saying, I think we need to require that each XA resource be >required to implement an MBean whose sole purpose is to obtain a reference to >an XAResource interface. So, here's what I had in mind: 1. JBoss Boots up. All MBeans are created and started. 2. JBoss ServerImpl broadcasts an MBean Startup Notification. (This is currently already coded). 3. RecoverManager MBean receives the "JBoss Started" notification and begins recovery. 4. RecoveryManager queries MBeanServer for all "Recovery" Mbeans. These "Recovery" Mbeans will provide references to their XAResources. 5. RecoveryManager performs recovery. 6. RecoveryManager tells all "Recovery" Mbeans that they are finished with the XAResources. anonymous wrote : | Care must be taken such that the recovery manager only tries to | recover transactions that were from a previous instances. | Using either a mark in the log of when it was restarted or by | recording the jvm id in the log record? | The RecoveryManager MBean can do this at start(). Just rename existing log files, or use a timestamp in the logfile name. Anyways...I think it would be better to have a specific logger than a DB. That way, we have ultimate speed, and we can have/control as many log files as we want. anonymous wrote : | We also want to fix this tight coupling of the TM and RARs to make this simpler. | Based on what I've said above, do we really need to fix the coupling? Problem is...is it ok to do recovery while a live system is running? Seems it would be ok as long as XAResource.recover does not return Xids of existing running transactions. anonymous wrote : | Also bear in mind that JBossMQ and other services(?) use a DataSource | to persist data. i.e. one XAResource uses another one as a delegate. | Although in this case, the delegate XAResource should never be taking | part in two phase commit!? This will take more thought when recovery is added to JMS. Isn't/doesn't the TM required to identify duplicate XAResources? Bill View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3860446#3860446 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3860446 ------------------------------------------------------- The SF.Net email is sponsored by: Beat the post-holiday blues Get a FREE limited edition SourceForge.net t-shirt from ThinkGeek. It's fun and FREE -- well, almost....http://www.thinkgeek.com/sfshirt _______________________________________________ JBoss-Development mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/jboss-development
