A Dimecres 06 Novembre 2002 22:19, Rick Reumann va escriure:
> On Wednesday, November 6, 2002, 4:05:45 PM, Antoni wrote:
>
> AR> Hi, I don't speak english very very well, so this is a bit
> AR> difficult for me to explain, but I'll try ;-) ....
>
> No problem. Most American's don't speak English very well
> (including myself I'm sure:)
>
:)
> AR> I have'nt looked at the beanutils Converter registration, do you have
> to AR> register a class or an instance?
>
> It registers an instance one time in the static block at the top
> of the action:
>
> static {
> DateBeanUtilsConverter dateConverter = new
> DateBeanUtilsConverter(); dateConverter.setFormatPattern( "MMddyyyy" );
> StringBeanUtilsConverterDate myStringConverter = new
> StringBeanUtilsConverterDate(); myStringConverter.setFormatPattern(
> "MMddyyyy" );
> ConvertUtils.register( dateConverter, java.util.Date.class );
> ConvertUtils.register( myStringConverter, String.class );
> }
>
> AR> The problem here is that if there is only one instance of your class,
> and AR> setFormatPattern is only called once, then if there are two request
> that AR> require the use of your class a the same time, served by different
> threads, AR> the parse method in your instance of SimpleDateFormat might be
> called AR> concurrently, so (as it isn't thread save) it might fail.
>
> I'm not sure how this would happen as Eddie have both pointed out
> that the static block will only get called one time regardless of
> how many instances are created (at least on a single JVM I'm
> pretty sure that's the case). (On top of that I'm pretty sure on
> one JVM user's all share one servlet instance unless you maybe use
> that SingleThreadModel which I think hands them out from a pool.
> Moot point though I think if I do the stuff in the static block.
> But I could be wrong).
The problem is not in the static code, the problem is reusing the same
instance of SimpleDateFormat
Your initial aproach is fine. But let see what could happen if you move the
SimpleDateFormat creation to the setFormatPattern method:
- when the class loader loads your Action the static bloc is executed:
1- an instance of your converter is created
2- the setFormatPattern is called and an instance off SimpleDateFormat is
created.
3- the converter instance is registered
- there are 2 request at the same time that target an action that uses
BeanUtils.copyProperties with a bean that has a Date.
- the 2 request are served by to differents threads A and B
4- thread A begins the execution of the Action.execute,
5- thread A begins the execution of BeanUtils.copyProperties
6- thread A begins the execution of DateBeanUtilsConverter.convert
7- thread A begins the execution of SimpleDateFormat.parse ....
8- thread A is stopped and thread B begins the execution
9- thread B begins the execution of the Action.execute,
10- thread B begins the execution of BeanUtils.copyProperties
11- thread B begins the execution of DateBeanUtilsConverter.convert
12- thread B begins the execution of SimpleDateFormat.parse ....
13- thread B is stopped and thread A begins the execution
14 - thread A continues the execution of SimpleDateFormat.parse , but a
internal attribute of SimpleDateFormat where modified and it fails.
The problem is that during execution of SimpleDateFormat.parse some private
fields of SimpleDateFormat are modified.
You can take a look at
http://developer.java.sun.com/developer/bugParade/bugs/4228335.html
for details on the format classes not being thread-save issue
--
To unsubscribe, e-mail: <mailto:struts-user-unsubscribe@;jakarta.apache.org>
For additional commands, e-mail: <mailto:struts-user-help@;jakarta.apache.org>
