DevForce 요청이 시간 초과되면 자동으로 재 시도됩니다. 이 동작은 포럼 here에서도 언급되었습니다. 해당 포럼 게시물에서 제안 된 해결 방법은 문제를 완전히 피하기 위해 제한 시간을 늘리는 것입니다. 우리에게는 이것이 가능한 해결책이 아닙니다. 우리가 알고있는 몇 가지 작업이 있습니다. 제한 시간이 초과되면 시간 초과가 증가하는 것은 용인 할 수없는 해결책입니다.DevForce 요청에 대한 자동 재 시도를 비활성화하는 방법
전화가 저장 프로 시저 쿼리 또는 InvokeServerMethod 호출 인 경우 악의적 인 호출 인 경우 idempotent이 아니므로 다시 시도하는 것이 안전하지 않으므로 좋지 않은 결과를 초래할 수 있습니다. 우리는 앱에서 그런 경우에 빠지기 시작했고 큰 고통을 겪고 있습니다. 간단한 예로는 항목의 복사본을 만드는 저장 프로 시저를 호출합니다. 복사본이 너무 오래 걸리면 재 시도가 계속되지만 3 개의 복사 작업이 모두 병행 중임을 의미합니다. 최종 결과는 최종 사용자가 오류를 얻는다는 것입니다 (세 번째 rety가 여전히 시간 초과되기 때문에)하지만 (결국) 항목의 세 복사본이됩니다 (저장 프로 시저가 결국 완료 될 것입니다 - 재시도 논리는 이전 요청 - 그리고 그러한 취소가 가능하지는 않은지는 확실하지 않습니다.) 그리고 이것이 더 좋은 예 중 하나입니다. 다른 경우 재 시도 된 작업으로 인해 더 심각한 문제가 발생할 수 있습니다. DevForce가 더 이상 저장에 대한 자동 재 시도를 수행하는
가 나는 6.1.6 release notes에서 볼 수 없습니다. 그 행동이 StoredProcedureQueries와 InvokeServerMethods로 확장 된 것을보고 싶습니다. 정상적인 EntityQuery 작업 (및 아마도 심지어 연결/연결 끊기 호출)에 대해서, 나는 잘 알고있다. 이것이 DevForce의 핵심에서 변경 될 수있는 것이 아니라면이를 구성 할 수있는 방법이 있습니까? 아니면이를 제어하는 코드를 삽입 할 수있는 맞춤식 방법을 제공 할 수 있습니까?
우리는 DevForce 2010 또는 2012에 대해 이야기하고 있습니까? DF2010에서 InvokeServerMethod는 SaveChanges와 마찬가지로 다시 시도하지 않아야합니다. DF2012에는 어떤 방식 으로든 자동 재 시도를 구성 할 수있는 뛰어난 기능 요청이 있습니다. 우선 우선 순위를 높이고이를 구현해야합니다. DF2010에 대한 기능 요청은 여전히 옵션이지만 우선 순위는 낮습니다. –
비동기 호출을 수행하는 경우 DF2012에서 CancellationToken을 사용하여 재시도 문제를 해결할 수도 있습니다. –
저는 DevForce 2012를 사용 중입니다. CancellationToken은 어떻게 도움이 될까요? 나는 내가 무엇을 취소 할 지 확신 할 수 없기 때문에 재시도를하는 사람이 아니다. 그런 종류의 취소는 저장 프로 시저 또는 다른 서버 측 작업을 중지하지 않을 것입니다, 그렇습니까? 클라이언트가 요청을 포기하는 것만으로도됩니까? –