Re: jdbc xa support
От | Oliver Jowett |
---|---|
Тема | Re: jdbc xa support |
Дата | |
Msg-id | 42E08A8E.5020807@opencloud.com обсуждение исходный текст |
Ответ на | Re: jdbc xa support (Michael Allman <msa@allman.ms>) |
Ответы |
Re: jdbc xa support
(Michael Allman <msa@allman.ms>)
|
Список | pgsql-jdbc |
Michael Allman wrote: > Without a length argument allowing the TM to tell the RM how many xids > it can take, it doesn't make sense to return "some" xids at a time. > Because how many "some" is is determined by the RM, not the TM, and that > defeats the purpose of the C version's approach. Well, personal preference perhaps, it seems fine to me to allow the RM to break up the list into more manageable parts if it wants to. For example, consider a Java RM that is implemented by JNI calls to a C implementation of the XA interface. >> For our JDBC implementation? Set a fetchsize on your query to >> something reasonable -- perhaps 500? -- and return up to that many >> Xids per call until you hit the end of the resultset, then return >> empty arrays thereafter until a new scan starts. > > Why 500? It's simpler to return all of them. Sure, it doesn't really matter either way, it's just an implementation decision. My only concern was if you're pulling in a million Xids at once then you are going to bloat out the heap more than you need to -- but that's unlikely to happen in any real system anyway. >>> Anyway, do you think my implementation of the recover() method >>> violates the JTA spec? >> >> >> The code in pgjdbcxa-20050721.jar appears to violate the spec, as you >> completely ignore the flags argument. You need to track the recovery >> scan state even if you decide to return all Xids in one array, because >> subsequent calls shouldn't return those Xids again until a new scan is >> started, per the API docs. > > > I do track the recovery scan state. Each call puts the scan cursor at > the end of the list. Uh, are we looking at the same code here? I don't see anything in the code from pgjdbcxa-20050721.jar that records whether we are at the end of the list or not between calls to recover(), and I don't see anything that looks for TMSTARTRSCAN to reset that state. If I've missed it, can you point it out to me? > I still don't see a violation of the API. The API says that if a TM does this: Xid[] xids_1 = resource.recover(TMSTARTRSCAN); Xid[] xids_2 = resource.recover(TMNOFLAGS); Xid[] xids_3 = resource.recover(TMNOFLAGS); then xids_1, xids_2, and xids_3 reflect consecutive (and possibly empty if you hit the end) parts of the recovery list. It seems your code does not respect this -- it will return the full list of Xids repeatedly in each of xids_1, xids_2 and xids_3. Given that the way that the TM decides that the recovery scan is complete is by looking for an empty array returned from recover(), your code is going to hit exactly the infinite-loop case described in the thread that Heikki posted. > It looks like the JTA API is wrong or there's a typo. If we follow the > spirit of the DTP spec it seems that the TMNOFLAGS flag means "return > some xids starting from where we last left off". I'm still not sure > what TMENDRSCAN means. The JTA specification is fairly clear about their meanings. TMNOFLAGS does indeed mean "continue the current scan". TMENDRSCAN means "I'm done with this scan", and allows RMs to free resources they have allocated for the scan. === The flag parameter indicates where the recover scan should start or end, or start and end. This method may be invoked one or more times during a recoveryscan. The resource manager maintains a cursor which marks the current position of the prepared or heuristically completed transaction list. Each invocation of the recover method moves the cursor past the set of Xids that are returned. [...] TMSTARTRSCAN - indicates that the recoveryscan should be started at the beginning of the prepared or heuristically completed transaction list. TMENDRSCAN - indicates that the recovery scan should be ended after the method returns the Xid list. If this flag is used in conjunction with the TMSTARTRSCAN, this method invocation starts and ends the recovery scan. TMNOFLAGS - this flag must be used when no other flags are specified. This flag may be used only if the recovery scan has already been started. The list of Xids are returned === -O
В списке pgsql-jdbc по дате отправления: