Hi
I feel this is the area where simple things become quite complicated.
What you actually want is a mean for maintaining a consistent state of a
counter.
The word consistent by itself sounds na?ve but actually hide a lot of
complexity.
This the exact place where simple file manipulation or logging facilities
breaks down.
Your real choices as I see it is use a db it can be relational of an ODBS
one.
As you know using a db for such a task may seems as an overkill but so is a
consistent updated file.
I will not cover to much on this option since there are planty of examples
out there for this method.
Since many of you are not aware of this option and since my expertise are
currently in the field of JINI and JavaSpaces I will focus on this option.
I think that JavaSpaces provide a very elegant and SIMPLE!! Approach for
such cases.
I will try to illustrate this in the following example:
First you need to define the counter:
Public class counter
Implements entry
{
public Object count;
}
Second is the application second:
1. get a reference to the space:
you could use utilities class that simplifies this task:
2. use the space api to update the entry
// the application code:
JavaSpace space = SpaceFinder.find("JINI://*/*/JavaSpaces");
counter = space.take( new Counter() , null ,timeout );
if ( counter == null )
//Initiate the counter
counter = new counter( new Integer(0) );
else
// increment the counter
counter.count = new Integer( counter.count.intValue() + 1 );
space.write( counter , null , lease );
System.out.println("the count is : " + counter.count );
----------------------------------------------------------------------------
---------------------
That is all that is needed. Simple isn't it ?
Detailed description:
The space finder is a utility that wrapps the various methods JINI provide
for service lookup. In general this format tells the lookup service to
search for a space in any place in the network and in any container with a
specific name of "JavaSpaces".
The find method returns the client of the space which implements the simple
space api.
This api includes a simple memory manipulation methods both in blocking
with timeout ) and none blocking format this includes the
Take , read , write methods.
The first parameter in the write method has a different role:
In the write method it is the used as the entry data by itself and in the
take it is used as a template ( a simplified sort of query ) which tells the
space that we are interested only with entries with from this class type or
any derivation of it.
Each operation can participate in a distributed transaction ( the second
parameter in the write and take ) . In our example we set this parameter to
null meaning we do not wish to participate in a transaction.
The third parameter provide a time dimension to the operation:
In the take this means how long we will wait for the arrival of such and
entry.
In the case of write this means how long we wish the entry will be stored in
the space.
The advantages In this approach are:
1. The space takes control in maintain the consistent state of the entry.
2. The space can be located in any place ( including your app vm ) no need
for complex configuration initiation.
3. The space stores the entry in either the memory or persistent backend
can be either ODBMS or RDBMS ) transparently. ( no need for schemas ,
mapping , pre-compilers etc ).
4. The entry can be easily shared between other distributed components
some of them may not have an access to the file system ).
5. Entry manipulation can be transactional.
There is much more into it I am sure that once you will start looking at
this you will find many other places where the space could save you a lot of
time.
I had listed some relevant articles in our web site
www.j-spaces.com/tech.html you can also look at the www.JINI.org web site.
You can also take a look at the following overview on this subject:
http://www.javaspaces.homestead.com/
Regards
Nati S.
"The space is the network www.j-spaces.com "
-----Original Message-----
From: A mailing list for discussion about Sun Microsystem's Java Servlet API
Technology. [mailto:[EMAIL PROTECTED]]On Behalf Of Wai Mun
Sent: Sat 02 June 2001 10:55
To: [EMAIL PROTECTED]
Subject: Re: counter file
thanks for the advice as well as nic.
i'm rather confused now, why must the file opening/closing be done in the
init? if so, then where should i place the code i.e. which servlet's init
the code should be placed?
& lastly, is it costly to open/close files everytime? what are the cons? &
pros if any? wats the best solution?
----- Original Message -----
From: "Christopher K. St. John" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Sunday, June 03, 2001 00:20
Subject: Re: counter file
> Nic Ferrier wrote:
> >
> > > Wai Mun <[EMAIL PROTECTED]> 02-Jun-01 3:26:00 PM >>>
> >
> > >how do i update the counter file efficiently?
> >
> > The constructor:
> > - creates a seperate thread for managing the file
> >
>
> If you create a thread in the init() method, you have
> to get rid of it in the destroy() method. But Java
> doesn't make it easy to get rid of threads: the thead
> itself has to cooperate, and be very carefully written.
> So if at all possible it's a good idea to avoid spawning
> threads in servlets.
>
> It might seem trivial (what's a couple of extra threads
> laying around?), but it's like not free'ing memory in
> C++: fine for little 5 line utilities, but in servers,
> leaks accumulate and are expensive to hunt down. Plus,
> it's just bad practice.
>
> Depending on the expected load, it might make sense to
> just try open/write/close-on-every-request and see
> if it really is a problem. Premature optimization is the
> root of all evil, etc.
>
> If that doesn't work, then Nic's idea works fine without
> using a thread if you have the log method itself write out
> the buffer once every 1000 (or 100 or 10 or whatever)
> requests. That way, the file i/o cost is amortized out over
> many requests. But remember to flush the buffer in the
> destroy() method of the servlet. And you might add a way
> for a servlet request to force a buffer flush.
>
>
> --
> Christopher St. John [EMAIL PROTECTED]
> DistribuTopia http://www.distributopia.com
>
>
___________________________________________________________________________
> To unsubscribe, send email to [EMAIL PROTECTED] and include in the
body
> of the message "signoff SERVLET-INTEREST".
>
> Archives: http://archives.java.sun.com/archives/servlet-interest.html
> Resources: http://java.sun.com/products/servlet/external-resources.html
> LISTSERV Help: http://www.lsoft.com/manuals/user/user.html
___________________________________________________________________________
To unsubscribe, send email to [EMAIL PROTECTED] and include in the body
of the message "signoff SERVLET-INTEREST".
Archives: http://archives.java.sun.com/archives/servlet-interest.html
Resources: http://java.sun.com/products/servlet/external-resources.html
LISTSERV Help: http://www.lsoft.com/manuals/user/user.html
___________________________________________________________________________
To unsubscribe, send email to [EMAIL PROTECTED] and include in the body
of the message "signoff SERVLET-INTEREST".
Archives: http://archives.java.sun.com/archives/servlet-interest.html
Resources: http://java.sun.com/products/servlet/external-resources.html
LISTSERV Help: http://www.lsoft.com/manuals/user/user.html
