2011-08-16 5 views
2

Play! ScriptEngine를 포함 해 javax.script 패키지를 많이 사용하는 프레임 워크입니다. ScriptEngine은 생성하는데 비용이 많이 들고 여러 요청에 걸쳐 사용하는 것이 합리적입니다 (적어도 하나의 Thread마다 하나씩 여러 개의 ScriptEngine을 만들 필요가 없습니다 - 적어도 각 요청마다 ScriptEngines을 만들지는 않을 것입니다).재생! 프레임 워크 : 여러 요청에 대한 인스턴스 재사용

이 사례는 ScriptEngines에 제한되지 않는다고 생각합니다. 그런 경우를 처리 할 수있는 프레임 워크에 뭔가가있을 수 있습니다.

아이디어를 제공해 주셔서 감사합니다. Malax

+0

하나의 정적 인스턴스만으로 충분하지 않습니까? Play 프레임 워크는 JEE 구성 요소 모델의 안티 테스팅으로, 요청 간에는 상태가 거의 유지되지 않습니다. – Jeremy

+0

그것은 첫 번째 시도였습니다. 하나의 스크립트 엔진의 정적 인스턴스가있었습니다. 이 문제는, ScriptEngine가 thread 세이브가 아니고, 요구가 thread 풀에 의해 dispatch되어 (정적 필드가 thread간에 공유되고 있기 때문에), 엔진이 다른 thread에 의해 동시에 사용되는 일이 있습니다. – Malax

답변

2

재생은 상태가 없으므로 개체를 사용자에게 연결하는 "세션 식"메커니즘이 없습니다. 다음 두 가지 대안을 사용할 수 있습니다.

캐시를 사용하십시오. 고유 한 ID로 캐시에 ScriptEngine을 저장하고 아직 존재하는지 확인하는 메소드를 추가하십시오. 다음과 같이하십시오 :

또는 ScriptEngine의 정적 인스턴스를 포함하는 싱글 톤 개체를 만들어 서버가 시작되면 항상 존재하게 만듭니다.

캐시 방법이 가장 좋습니다.

편집 : 귀하의 코멘트에,이 상황에 따라 달라집니다 :

  1. 고유 한 사용자의 여러 요청 (즉, 각 사용자가 작업 할 자신의 ScriptEngine을 가지고있다)에 걸쳐 엔진을 다시 사용하려는 경우 캐시 메소드는 캐시가 엔진을 사용자 ID에 링크하기 때문에 작동합니다. 이렇게하면 모든 스레딩 문제도 해결됩니다.
  2. 그렇지 않으면 여러 사용자의 여러 요청에서 다시 사용하려는 경우 정적 방법이 더 나은 방법입니다. 그러나 액세스가 스레드 또는 Play 또는 다른 시스템에서 안전하지는 않습니다.

나는 그 (것)들과 비동기 적으로 일하기위한 것이라고 생각하고 있습니다. 난 당신이 ScriptEngines에를 사용하는 방법을 알고 있지만, 이런 일을하려고하지 않습니다 요청에

  • 이 같은 요청에서는 ScriptEngine의 처리 요구
  • 마킹 DB에서 테이블에 엔트리를 저장을 asynchronous 작업 시작 (또는 30 초마다 실행 중임)
  • 작업이 테이블의 첫 번째 항목을 읽고 제거한 후 작업을 수행하고 사용자에게 응답을 보냅니다. 그 일에는 사용할 ScriptEngine 풀이있을 수 있습니다.
  • 현재 작업이 진행되는 동안 작업이 다시 시작되지 않으므로 충분한 요청이 있으면 작업이 중단되지 않습니다. 그것은 당신이 그 당시에 엔진을 필요로하지 않는다는 것을 의미하며, 요청에 따라 다시 만들어 질 것입니다.

이렇게하면 스레드 문제를 무시하고 풀에서 선형으로 작업 할 수 있습니다. 그렇게 할 수 없다면 다중 스레드를 생성하는 서버 환경에서 스레드 안전하지 않은 객체를 가장하지 못하기 때문에 ScriptEngine의 스레드 안전성을 수정해야합니다.

+0

에 대한 정적 인스턴스 - 주요 질문에 대한 내 의견을 참조하십시오. 문제는 캐시 솔루션에서도 발생하는 것으로 보입니다. : ( – Malax

+0

+1 풀 사용시. – Jeremy

0

왜 Script-Pool을 구현하지 않습니까? 따라서 각 요청은 JDBC-Connection-Pool과 같은 방식으로 풀에서 인스턴스를 가져옵니다. 그러나 Script-Engine이 stateless인지 확인하십시오.

관련 문제