I glanced over it, it looks okay. A few notes:
You didn't give the package name for Logger, Money, or Scalar, so I can't
comment on them, although Log4j's Logger is thread safe, and I would guess
most loggers are.
Pattern is thread safe, but note that Matcher is not.

Yes, it is just a matter of looking through any objects that you initialize
in the Page class, outside of a method. An alternative is to create any
variables you need in setupRender() rather than when you declare them in the
class, only moving them out if they cause poor performance (and checking
that they're thread safe beforehand). My coding style normally is not to
have many objects like that in the page class, instead having them in
services.

Attachment text for the archives:

In the release notes for T.5.2.0
(http://tapestry.apache.org/release-notes-52.html#ReleaseNotes5.2-Tap5.2.0)
there is a section on references to non thread-safe objects and the impact
upon them of the removal of Page Pooling, using:



private final DateFormat format =
DateFormat.getDateInstance(DateFormat.MEDIUM, locale);



... as a problem example.  I have a few examples below of some code I am
using and am concerned about introducing subtle bugs that are difficult to
track down.



private final static Logger log =
LoggerFactory.getLogger(VitasBasePage.class);



public static final Money MAX_VALUE = new Money("999999999999.999999");

public static final Currency DEFAULT_CURRENCY = Currency.getInstance("EUR");



public static final boolean USE_PRODUCTION_PORTS =
!("false".equals(System.getProperty(PRODUCTION_PORTS_PARAM)));



private static final int ROUNDING_MODE = BigDecimal.ROUND_HALF_EVEN;



public static final Scalar HALF = new Scalar("0.5");



static final String VALIDATOR_PATTERN="(?<!\\\\)\\s*,\\s*(?!([0-9]*\\}))";

private final Pattern validatorPattern = Pattern.compile(VALIDATOR_PATTERN);



  public static final String DATE_FORMAT_NOW = "yyyy-MM-dd HH:mm:ss";

  public static final int MILLISECS_PER_DAY = 86400000;



  public static String now() {

    Calendar cal = Calendar.getInstance();

    SimpleDateFormat sdf = new SimpleDateFormat(DATE_FORMAT_NOW);

    return sdf.format(cal.getTime());



  }



public static String now(String dateFormat) {

                    Calendar cal = Calendar.getInstance();

                    SimpleDateFormat sdf = new SimpleDateFormat(dateFormat);

                    return sdf.format(cal.getTime());



}








On Fri, Jan 21, 2011 at 5:07 PM, Jim O'Callaghan <jc1000...@yahoo.co.uk>wrote:

> The spam filter has blocked this email up to the 4th attempt so I've put
> most of it into the attached text file.
>
> The query relates to thread safety, specifically the example in the T.5.2.0
> release notes
> (http://tapestry.apache.org/release-notes-52.html#ReleaseNotes5.2-Tap5.2.0
> )
>
> Anyone care to have a quick glance at the attachment for coding red flags
> they could highlight, or even just advise on whether it is a question of
> tracking down third party source to check if there are thread safety issues
> in any of their called methods?  Thanks a million.
>
> Regards,
> Jim.
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org
> For additional commands, e-mail: users-h...@tapestry.apache.org
>

Reply via email to