This is an issue that I have never considered so I really appreciate you
raising it.
JCAM is most definitely not ThreadSafe as it changes the Template during the
validation process so that you HAVE to reread the template file every time it
is used. This was one of the reasons for considering changing to CAMV. However
as I have never considered it in CAMV either I am not able to confirm that it
is Thread safe.
Can you please explain you usecase for the validation. Are you trying to read
the Template in once and use it to validate many xml files in different
threads. In the case of CAMV it would be necessary to make the
TemplateValidator Thread Safe so that you could use in in many threads. The
current implementation has some faults in that the errors are held in a static
list which would get all messed up. I think that your need for it to be Thread
Safe is a valid change request - even a bug and I will investigate making the
necessary changes to allow this to happen.
One of the immediate changes I will try to implement is to remove the use of
any static variables with in CAMV. I will also remove the use of Static
functions so that there is no confusion as to which variable is being used. If
any Static functions remain I will make them Thread safe.
Thanks again for your very useful input.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Thanks for the confirmation.
There are two scenarios here:
As there are multiple threads trying to validate different XMLs concurrently, JCAM started giving multiple errors which are random in nature e.g. NullPointerException, TrimmerException etc.
We are caching the template in memory so that each request need not perform disk io to load it in memory. Understanding was template should be used for "reference" and does not gets modified with each request and should be able to be used by multiple threads.
Please do let me know if you want me to raise a feature request or bug and for
which one we can get a fix soon, JCAM or CAMV?
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Sadly, although your assumption would be expected to be correct, in JCAM I use
the JDOM Libraries to contract and expand the underlying JDOM model of the
template during processing. This means that the template is not immutable. One
way round this would be to use the cloning function on the Template Document
before calling the processor. That way the template you use will be a new copy
of one each time it is used and in theory should have no links back to the
original one that has been loaded off the file. This would of course have a
timing implication but may enable you to get round the problem.
So you could use:
2009-11-09 22:23:32 GMT
Currently I am using JCAM in a manged environment (deployed in WebSphere
Application Server) and apparently it is not threadsafe.
Currently I am using JCAM in a manged environment (deployed in WebSphere
Application Server) and apparently it is not threadsafe.
JCam processor = new JCam(JCam.Options.VALIDATE, templateDocument,
xmlDocument, parameters);
resultDocument = processor.run(orderType);
Is it s usage issue i.e. the way I am using or it is a design issue?
Also is CAMV thread safe?
This is an issue that I have never considered so I really appreciate you
raising it.
JCAM is most definitely not ThreadSafe as it changes the Template during the
validation process so that you HAVE to reread the template file every time it
is used. This was one of the reasons for considering changing to CAMV. However
as I have never considered it in CAMV either I am not able to confirm that it
is Thread safe.
Can you please explain you usecase for the validation. Are you trying to read
the Template in once and use it to validate many xml files in different
threads. In the case of CAMV it would be necessary to make the
TemplateValidator Thread Safe so that you could use in in many threads. The
current implementation has some faults in that the errors are held in a static
list which would get all messed up. I think that your need for it to be Thread
Safe is a valid change request - even a bug and I will investigate making the
necessary changes to allow this to happen.
One of the immediate changes I will try to implement is to remove the use of
any static variables with in CAMV. I will also remove the use of Static
functions so that there is no confusion as to which variable is being used. If
any Static functions remain I will make them Thread safe.
Thanks again for your very useful input.
Thanks for the confirmation.
There are two scenarios here:
As there are multiple threads trying to validate different XMLs concurrently, JCAM started giving multiple errors which are random in nature e.g. NullPointerException, TrimmerException etc.
We are caching the template in memory so that each request need not perform disk io to load it in memory. Understanding was template should be used for "reference" and does not gets modified with each request and should be able to be used by multiple threads.
Please do let me know if you want me to raise a feature request or bug and for
which one we can get a fix soon, JCAM or CAMV?
Sadly, although your assumption would be expected to be correct, in JCAM I use
the JDOM Libraries to contract and expand the underlying JDOM model of the
template during processing. This means that the template is not immutable. One
way round this would be to use the cloning function on the Template Document
before calling the processor. That way the template you use will be a new copy
of one each time it is used and in theory should have no links back to the
original one that has been loaded off the file. This would of course have a
timing implication but may enable you to get round the problem.
So you could use:
2009-11-09 22:23:32 GMT
Currently I am using JCAM in a manged environment (deployed in WebSphere
Application Server) and apparently it is not threadsafe.
JCam processor = new JCam(JCam.Options.VALIDATE,
(Document)templateDocument.clone, xmlDocument, parameters);
resultDocument = processor.run(orderType);
This may help in the short term, but may not fix all the Threading issues.
If you could raise a BUG against CAMV I will undertake to do some work to make
sure this works better in that code.
Ok we tried with the suggested cloning of template. It certainly reduces the
instances of errors but does not solves the issue.
For CAMV I have raised a bug for code to be thread-safe. Is it possible to
make those changes to JCAM as well?
Also what timelines are we looking for these changes?