KSChan wrote:
> Paul,
>
> I didn't recognize the String mutex = "" is a constant ^^" since it
> works, i use it -.-"
>
> Do you mean that the mutex must declared with static modifier so that i
> could work?
>
I would recommend using a private static field value, for example:
private static final Object mutex = new Object();
as using "" could lead to some *very* nasty bugs that will be very hard
to track down. For example, if you or someone else uses it independently
for synchronization of other code blocks in the same VM.
An alternative, if you are comfortable using it, is to change the
lifecycle of the resource:
@UriTemplate( "/draft" )
@ProduceMime( "text/xml" )
@ConsumeMime( "application/x-www-form-urlencoded" )
@Singleton
class Draft {
@UriTemplate( "/aTemplate" )
@HttpMethod( "GET" )
public Response webServiceOperation( ... ) {
synchronized ( this ) {
// obtain JDBC connection here
}
// carry DB operation here
}
}
The @Singleton means that only one instance of Draft will be created and
the method webServiceOperation is reentrant for multiple requests. There
are certain restrictions: there must be a constructor that takes zero
parameters.
I personally recommend that developers avoid the use of this life-cycle
mode unless they really require it as the per-request avoids concurrency
issues at least in the resources (but not always from other areas as you
have found out!) and can make programming resources DRYer.
> I have another question ...
>
> What is the difference between Jersey and Metro in the glassfish project
> ?? I think they are both dealing with web service ...
>
Good question.
Metro is Sun's deliverable for "Web services" whether they be WS-* or
RESTful.
We do plan to bundle Jersey with Metro in the future. The delay in doing
this is not really technical. We cannot legally include any stuff that
implements a non-final jar into FCS distributions of Metro. So we would
need to bundle in a non-FCS version of Metro that is not used in any of
our products (like GF) or we will wait until Jersey goes FCS (which is
currently planned for September). Currently we plan to do the latter.
Part of our responsibility is to educate developers on which style of
Web service development to use with Metro (when Jersey ships with it)
for developing distributed applications. I know which one i prefer :-)
My opinion is: use WS-* when you have to, otherwise consider the REST
architectural style, but don't use it for everything "just out of
architectural purity" [*].
Paul.
[*] Roy Fielding said it based on rest-discuss:
"And let's not forget that there are many network-based applications
for which REST is not likely to be a good design (an alarm monitoring
system would be one example -- it may have RESTful components, such
as a status view, but it would be silly to restrict the sensors to a
pull-based interaction just out of architectural purity)."
--
| ? + ? = To question
----------------\
Paul Sandoz
x38109
+33-4-76188109