You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@struts.apache.org by Rick Reumann <ma...@reumann.net> on 2002/11/06 21:37:11 UTC
Re[2]: java.util.Date
On Wednesday, November 6, 2002, 3:21:28 PM, Antoni wrote:
AR> Keep in mind that DateFormat (and SimpleDateFormat) is not thread safe so you
AR> have to be very careful when reusing them.
I like Max's suggestion though. I think I will move it to the
setFormatPattern for sure. Correct me if I'm wrong here...
Since the registration of this Converter takes places in a static
block in the top of my DispatchAction the setFormatPattern should
only be called once, since isn't only once instance of my
DispatchAction created (and thus only one initial load in the
static block?). I guess I could be extra careful and synchronize
setFormatPattern since I don't think that should incur too much
overhead since in my situation I can imagine more than one
instance of the Action class being created.
--
Rick
mailto:maillist@reumann.net
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Re[6]: java.util.Date
Posted by Antoni Reus <an...@wanadoo.es>.
A Dimecres 06 Novembre 2002 22:55, Rick Reumann va escriure:
> On Wednesday, November 6, 2002, 4:51:58 PM, Antoni wrote:
>
> AR> The problem is that during execution of SimpleDateFormat.parse some
> private AR> fields of SimpleDateFormat are modified.
>
> Ahhhh yes thank you. I bet I have this problem in other pieces of
> my code as well. What would you recommend doing? Should I
> synchronize the convert() method? or should I do it like I
> initially had it where I created a separate instance of
> SimpleDateFormat each time in the convert method? Which would
> incur less overhead and be faster? Or maybe neither of the above
> approaches is correct?
>
Your approaches are correct.
I haven't made any tests but I think that in most cases the faster method
would be to synchronize on the SimpleDateFormat object before calling to
format or parse.
> Thanks again for making this clearer.
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re[6]: java.util.Date
Posted by Rick Reumann <ma...@reumann.net>.
On Wednesday, November 6, 2002, 4:51:58 PM, Antoni wrote:
AR> The problem is that during execution of SimpleDateFormat.parse some private
AR> fields of SimpleDateFormat are modified.
Ahhhh yes thank you. I bet I have this problem in other pieces of
my code as well. What would you recommend doing? Should I
synchronize the convert() method? or should I do it like I
initially had it where I created a separate instance of
SimpleDateFormat each time in the convert method? Which would
incur less overhead and be faster? Or maybe neither of the above
approaches is correct?
Thanks again for making this clearer.
--
Rick
mailto:maillist@reumann.net
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Re[4]: java.util.Date
Posted by Antoni Reus <an...@wanadoo.es>.
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: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Re[4]: java.util.Date
Posted by Antoni Reus <an...@wanadoo.es>.
Hi,
A Dimecres 06 Novembre 2002 22:31, Kris Schneider va escriure:
> Apologies if I'm misinterpreting, but I think Antoni's concern is that the
> SimpleDateFormat's parse and format methods are not thread-safe. The
> creation of the converters and their registration can obviously be
> accomplished in a thread-safe manner, but if multiple threads call into
> parse and/or format at the same time, this will cause a problem. If that's
> not what Antoni was saying...it's still a problem ;-). Shouldn't you code a
> Converter's convert method with the same approach to thread-safety as an
> Action's execute/perform method? If your Converter maintains a
> SimpleDateFormat instance field that it uses to either format or parse,
> it's not thread safe.
>
That's exactly what I was trying to say!
Thanks for the clarification
> Quoting Rick Reumann <ma...@reumann.net>:
> > 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).
> >
> > --
> >
> > Rick
> > mailto:maillist@reumann.net
> >
> >
> > --
> > To unsubscribe, e-mail:
> > <ma...@jakarta.apache.org>
> > For additional commands, e-mail:
> > <ma...@jakarta.apache.org>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: java.util.Date
Posted by Kris Schneider <kr...@dotech.com>.
All I meant was that there's a similarity between a single Action instance
having multiple threads comcurrently invoke its execute/perform method and a
single Converter instance having multiple threads concurrently invoke its
convert method. Same deal with a single HttpServlet instance having multiple
threads concurrently invoke its doGet/doPost methods. In each case, you really
want to keep static and instance fields that maintain state for a given method
invocation out of the equation. If you do make use of those fields, you have to
provide synchronization. The downside to synchronization is that it can impact
throughput and potentially cause deadlock.
That being said, in general I'd recommend creating a new instance instead of
introducing synchronization. The interesting twist with SimpleDateFormat is
that there appears to be a reported issue with excessive String creation in the
bug report that Antoni referenced (4228335). It looked like one of the
reviewers couldn't reproduce the results, but it's something to keep in mind.
Quoting Rick Reumann <ma...@reumann.net>:
>
>
> On Wednesday, November 6, 2002, 4:31:09 PM, Kris wrote:
>
> KS> The creation of the converters and their registration can
> KS> obviously be accomplished in a thread-safe manner, but if multiple
> KS> threads call into parse and/or format at the same time, this will
> KS> cause a problem. If that's not what Antoni was saying...it's still
> KS> a problem ;-). Shouldn't you code a Converter's convert method
> KS> with the same approach to thread-safety as an Action's
> KS> execute/perform method? If your Converter maintains a
> KS> SimpleDateFormat instance field that it uses to either format or
> KS> parse, it's not thread safe.
>
> Thank you as well Kris. I'm looking at the Struts Action
> execute/perform methods and I'm not sure how the situation is the
> same though. I'll look at them some more.
>
> Thanks guy for bringing this thread safe issue to my attention.
>
>
>
>
> --
>
> Rick
> mailto:maillist@reumann.net
>
>
> --
> To unsubscribe, e-mail:
> <ma...@jakarta.apache.org>
> For additional commands, e-mail:
> <ma...@jakarta.apache.org>
>
--
Kris Schneider <ma...@dotech.com>
D.O.Tech <http://www.dotech.com/>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re[6]: java.util.Date
Posted by Rick Reumann <ma...@reumann.net>.
On Wednesday, November 6, 2002, 4:31:09 PM, Kris wrote:
KS> The creation of the converters and their registration can
KS> obviously be accomplished in a thread-safe manner, but if multiple
KS> threads call into parse and/or format at the same time, this will
KS> cause a problem. If that's not what Antoni was saying...it's still
KS> a problem ;-). Shouldn't you code a Converter's convert method
KS> with the same approach to thread-safety as an Action's
KS> execute/perform method? If your Converter maintains a
KS> SimpleDateFormat instance field that it uses to either format or
KS> parse, it's not thread safe.
Thank you as well Kris. I'm looking at the Struts Action
execute/perform methods and I'm not sure how the situation is the
same though. I'll look at them some more.
Thanks guy for bringing this thread safe issue to my attention.
--
Rick
mailto:maillist@reumann.net
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
A form with Collection of beans
Posted by Vipul Sagare <vi...@yahoo.com>.
I am using Struts 1.0.2. I have a form bean which has collection of
other beans. How could I present this in <html:form> and retrieve
users input for the form(for each beans in collection)?
I came across Struts Nesting extension on KeyboardMonkey.com. Is it
1.0.2 compatible? If yes, what do I need?
Your help is appreciated. Thank you.
Vipul
__________________________________________________
Do you Yahoo!?
U2 on LAUNCH - Exclusive greatest hits videos
http://launch.yahoo.com/u2
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: java.util.Date
Posted by Eddie Bush <ek...@swbell.net>.
I don't think it's your fault, Max. The docs should talk about that
internal Calendar instance. Knowing things like that .oO( Hrm ... if it
just has a single internal Calendar instance, it's probably doing
modification to it on-the-fly ...) is quite important! If the only
thing involved were the format, I think your apporach of moving things
to a static initializer would have been the way to do it. Sounds like
that's not the way to do it though :-(
Max Kutny wrote:
> EB> from javadoc on SimpleDateFormat: Synchronization
>
> EB> Date formats are not synchronized. It is recommended to create
> EB> separate format instances for each thread. If multiple threads access
> EB> a format concurrently, it must be synchronized externally.
>
> EB> ... so your concern is quite valid ... kind of. The time I could see
> EB> a problem arising would be when you are *changing* the format.
>
>That's exactly as I understood javadoc. *formats* are not
>synchronized. Since format is applyed in static code I suggested to move
>SimpleDateFormat creation there. Seems I was wrong. That's javadoc
>ambiguously.
>
>Sorry all guys for confusing you.
>
>
--
Eddie Bush
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: java.util.Date
Posted by Max Kutny <mk...@umc.com.ua>.
EB> from javadoc on SimpleDateFormat: Synchronization
EB> Date formats are not synchronized. It is recommended to create
EB> separate format instances for each thread. If multiple threads access
EB> a format concurrently, it must be synchronized externally.
EB> ... so your concern is quite valid ... kind of. The time I could see
EB> a problem arising would be when you are *changing* the format.
That's exactly as I understood javadoc. *formats* are not
synchronized. Since format is applyed in static code I suggested to move
SimpleDateFormat creation there. Seems I was wrong. That's javadoc
ambiguously.
Sorry all guys for confusing you.
--
Max Kutny
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: java.util.Date
Posted by Kris Schneider <kr...@dotech.com>.
No problem - it's all Rick and Antoni's fault anyway for bringing it up
:-D.
Eddie Bush wrote:
>
> !!! Gotcha! Ok - I can see where that might pose a serious issue!
> Sorry for being stubborn :-)
>
> Kris Schneider wrote:
>
> >But the thread-safety issue really *is* with the parse and format
> >methods. The problem is that SimpleDateFormat uses a protected Calendar
> >instance field (inherited from DateFormat) to maintain state specific to
> >an invocation of both parse and format. So, multiple concurrent threads
> >entering the parse and/or format methods of a single SimpleDateFormat
> >instance are gonna tromp all over the state of that Calendar field.
> >
>
> --
> Eddie Bush
>
> --
> To unsubscribe, e-mail: <ma...@jakarta.apache.org>
> For additional commands, e-mail: <ma...@jakarta.apache.org>
--
Kris Schneider <ma...@dotech.com>
D.O.Tech <http://www.dotech.com/>
Re: java.util.Date
Posted by Eddie Bush <ek...@swbell.net>.
!!! Gotcha! Ok - I can see where that might pose a serious issue!
Sorry for being stubborn :-)
Kris Schneider wrote:
>But the thread-safety issue really *is* with the parse and format
>methods. The problem is that SimpleDateFormat uses a protected Calendar
>instance field (inherited from DateFormat) to maintain state specific to
>an invocation of both parse and format. So, multiple concurrent threads
>entering the parse and/or format methods of a single SimpleDateFormat
>instance are gonna tromp all over the state of that Calendar field.
>
--
Eddie Bush
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: java.util.Date
Posted by Kris Schneider <kr...@dotech.com>.
But the thread-safety issue really *is* with the parse and format
methods. The problem is that SimpleDateFormat uses a protected Calendar
instance field (inherited from DateFormat) to maintain state specific to
an invocation of both parse and format. So, multiple concurrent threads
entering the parse and/or format methods of a single SimpleDateFormat
instance are gonna tromp all over the state of that Calendar field.
Eddie Bush wrote:
>
> from javadoc on SimpleDateFormat:
>
> Synchronization
>
> Date formats are not synchronized. It is recommended to create separate
> format instances for each thread. If multiple threads access a format
> concurrently, it must be synchronized externally.
>
> ... so your concern is quite valid ... kind of. The time I could see a
> problem arising would be when you are *changing* the format. All
> methods that do not depend on instance-level variables would enjoy
> thread-safe-ness. My suspicion is that the format and parse methods
> would rely on the pattern, which seems to be a instance variable. So
> ... as long as you don't change the pattern you should still be fine ...
> I think.
>
> Did I miss something else?
>
> In other words: Assuming you use one pattern everywhere - and assuming
> you set that pattern in the static initializer for the class using the
> SimpleDateFormat (notice that I'm basically saying that pattern is never
> modified in more than a single thread at a time), everything should be
> ... just fine. Right? I can't see parse and format being
> non-threadsafe assuming pattern does not change.
>
> Now, if you wanted to be able to actually *change* the format being used
> in the middle somewhere ... you would have a possible problem :-) Until
> you have a need to do that, you don't need to synchronize.
>
> Kris Schneider wrote:
>
> >Apologies if I'm misinterpreting, but I think Antoni's concern is that the
> >SimpleDateFormat's parse and format methods are not thread-safe. The creation
> >of the converters and their registration can obviously be accomplished in a
> >thread-safe manner, but if multiple threads call into parse and/or format at
> >the same time, this will cause a problem. If that's not what Antoni was
> >saying...it's still a problem ;-). Shouldn't you code a Converter's convert
> >method with the same approach to thread-safety as an Action's execute/perform
> >method? If your Converter maintains a SimpleDateFormat instance field that it
> >uses to either format or parse, it's not thread safe.
> >
>
> --
> Eddie Bush
>
> --
> To unsubscribe, e-mail: <ma...@jakarta.apache.org>
> For additional commands, e-mail: <ma...@jakarta.apache.org>
--
Kris Schneider <ma...@dotech.com>
D.O.Tech <http://www.dotech.com/>
Re: java.util.Date
Posted by Eddie Bush <ek...@swbell.net>.
from javadoc on SimpleDateFormat:
Synchronization
Date formats are not synchronized. It is recommended to create separate
format instances for each thread. If multiple threads access a format
concurrently, it must be synchronized externally.
... so your concern is quite valid ... kind of. The time I could see a
problem arising would be when you are *changing* the format. All
methods that do not depend on instance-level variables would enjoy
thread-safe-ness. My suspicion is that the format and parse methods
would rely on the pattern, which seems to be a instance variable. So
... as long as you don't change the pattern you should still be fine ...
I think.
Did I miss something else?
In other words: Assuming you use one pattern everywhere - and assuming
you set that pattern in the static initializer for the class using the
SimpleDateFormat (notice that I'm basically saying that pattern is never
modified in more than a single thread at a time), everything should be
... just fine. Right? I can't see parse and format being
non-threadsafe assuming pattern does not change.
Now, if you wanted to be able to actually *change* the format being used
in the middle somewhere ... you would have a possible problem :-) Until
you have a need to do that, you don't need to synchronize.
Kris Schneider wrote:
>Apologies if I'm misinterpreting, but I think Antoni's concern is that the
>SimpleDateFormat's parse and format methods are not thread-safe. The creation
>of the converters and their registration can obviously be accomplished in a
>thread-safe manner, but if multiple threads call into parse and/or format at
>the same time, this will cause a problem. If that's not what Antoni was
>saying...it's still a problem ;-). Shouldn't you code a Converter's convert
>method with the same approach to thread-safety as an Action's execute/perform
>method? If your Converter maintains a SimpleDateFormat instance field that it
>uses to either format or parse, it's not thread safe.
>
--
Eddie Bush
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Re[4]: java.util.Date
Posted by Kris Schneider <kr...@dotech.com>.
Apologies if I'm misinterpreting, but I think Antoni's concern is that the
SimpleDateFormat's parse and format methods are not thread-safe. The creation
of the converters and their registration can obviously be accomplished in a
thread-safe manner, but if multiple threads call into parse and/or format at
the same time, this will cause a problem. If that's not what Antoni was
saying...it's still a problem ;-). Shouldn't you code a Converter's convert
method with the same approach to thread-safety as an Action's execute/perform
method? If your Converter maintains a SimpleDateFormat instance field that it
uses to either format or parse, it's not thread safe.
Quoting Rick Reumann <ma...@reumann.net>:
> 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).
>
> --
>
> Rick
> mailto:maillist@reumann.net
>
>
> --
> To unsubscribe, e-mail:
> <ma...@jakarta.apache.org>
> For additional commands, e-mail:
> <ma...@jakarta.apache.org>
>
--
Kris Schneider <ma...@dotech.com>
D.O.Tech <http://www.dotech.com/>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re[4]: java.util.Date
Posted by Rick Reumann <ma...@reumann.net>.
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).
--
Rick
mailto:maillist@reumann.net
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Re[2]: java.util.Date
Posted by Antoni Reus <an...@wanadoo.es>.
Hi, I don't speak english very very well, so this is a bit difficult for me to
explain, but I'll try ;-) ....
see below ...
A Dimecres 06 Novembre 2002 21:37, Rick Reumann va escriure:
> On Wednesday, November 6, 2002, 3:21:28 PM, Antoni wrote:
>
>
> AR> Keep in mind that DateFormat (and SimpleDateFormat) is not thread safe
> so you AR> have to be very careful when reusing them.
>
> I like Max's suggestion though. I think I will move it to the
> setFormatPattern for sure. Correct me if I'm wrong here...
>
> Since the registration of this Converter takes places in a static
> block in the top of my DispatchAction the setFormatPattern should
> only be called once, since isn't only once instance of my
> DispatchAction created (and thus only one initial load in the
> static block?). I guess I could be extra careful and synchronize
> setFormatPattern since I don't think that should incur too much
> overhead since in my situation I can imagine more than one
> instance of the Action class being created.
I have'nt looked at the beanutils Converter registration, do you have to
register a class or an instance?
The problem here is that if there is only one instance of your class, and
setFormatPattern is only called once, then if there are two request that
require the use of your class a the same time, served by different threads,
the parse method in your instance of SimpleDateFormat might be called
concurrently, so (as it isn't thread save) it might fail.
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re[2]: java.util.Date
Posted by Rick Reumann <ma...@reumann.net>.
On Wednesday, November 6, 2002, 4:47:32 PM, Eddie wrote:
EB> static blocks are run with the class - right? So it's really
EB> irrelevant how many instances get created - that code is run a
EB> maximum of one time - when the class is first loaded.
EB> Am I wrong?
Right that's what I was thinking as well... I just didn't know of
the implications if the stuff was on multiple servers and all that
jazz (jazz that I know nothing about:)
--
Rick
mailto:maillist@reumann.net
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: java.util.Date
Posted by Eddie Bush <ek...@swbell.net>.
static blocks are run with the class - right? So it's really irrelevant
how many instances get created - that code is run a maximum of one time
- when the class is first loaded.
Am I wrong?
Rick Reumann wrote:
>On Wednesday, November 6, 2002, 3:21:28 PM, Antoni wrote:
>
>
>AR> Keep in mind that DateFormat (and SimpleDateFormat) is not thread safe so you
>AR> have to be very careful when reusing them.
>
> I like Max's suggestion though. I think I will move it to the
> setFormatPattern for sure. Correct me if I'm wrong here...
>
> Since the registration of this Converter takes places in a static
> block in the top of my DispatchAction the setFormatPattern should
> only be called once, since isn't only once instance of my
> DispatchAction created (and thus only one initial load in the
> static block?). I guess I could be extra careful and synchronize
> setFormatPattern since I don't think that should incur too much
> overhead since in my situation I can imagine more than one
> instance of the Action class being created.
>
--
Eddie Bush
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>