Re: WEB Application need to upload a txt / csv file with 100K records

2010-11-17 Thread Marian Simpetru
Hi,

you can do this using some ajax:

First upload the file
then in the returning JSP you will have a ajax request that check the
status of the process. You can check the validation process, then the
actual database insert.
The resource checked will return the message (and depending of the
returned message you display 'under processing' or the error message or
whatever you need.

Best,

Marian



On Wed, 2010-11-17 at 18:11 +0530, Karthik Nanjangude wrote:

 Hi
 
 SPEC :
 
 JDK1.5
 WEB SERVER : TOMCAT 5.0.20
 O/s  Linux - Unix
 DB Oracle 10gAS + PLSQL
 
 Logged Session Time
 
 An module of our WEB Application need to upload a  txt / csv  file with  100K 
 records.
 These Records are to be validated with certain checks in the Business 
 layer..Before the pumped to a PLSQL of Oracle DB
 The process has to further Waite for the response of Errors from PLSQL and 
 has to be displayed on the JSP Screen.
 
 Question  :  I fear the  Login session time out may NOT commit the Process 
 for 100K records.
 
 
 Can some body suggest me a better way of handling the same successfully 
 .:(
 
 
 
 
 
 
 
 with regards
 
 N.S.Karthik
 




Re: httpd vs. Tomcat performance

2010-03-25 Thread Marian Simpetru
Hi ,

We have a online shop developed as a suite of JSR168 portlets. On some
portlets we list products and images (so there are about 25 images per
page + other images).
One image has around 250k.

Performance was greatly improved after we put apache httpd in front
(images served by apache  gzipped response for js, html, css). 
We  did not note  numbers, but the improvement could be seen with naked
eye.

Now, reading the article, I think we should have tried APR also :) 
But hei, there are other reasons too for using httpd, such as handful
apache modules (e.g. mod rewrite or gzip compression) 

Note: 
tomcat 6.0.18,  NOT configured with APR
running on debian linux sun jdk6 


Regards,
Marian Simpetru



On Thu, 2010-03-25 at 02:39 +0100, Rémy Maucherat wrote:

 On Thu, Mar 25, 2010 at 1:50 AM, Mark Thomas ma...@apache.org wrote:
  Chris deserves a lot of the credit. Without his figures, it is just opinion.
 
 That's the second benchmark that I see today that has odd numbers.
 
 Rémy
 
 -
 To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
 For additional commands, e-mail: users-h...@tomcat.apache.org
 


JSESSIONID and impact on google

2010-02-09 Thread Marian Simpetru
Hi!

I run a tomcat-based portal (Liferay) and we did nice work with it. When
it came to google, we realized we are punished for using tomcat, since
there seems to be no way in disabling jsessionid (session id appended to
URL). Google act as a non cookie browser and hence he is served with non
unique URLs (because of session ID is appended to URL).

I think is a shame for google not being able to strip that part, but
that's life.

Question is: Is there a way to configure tomcat to only use cookies (not
append jsessionid to URL for cookie0less browsers). I've been told Jetty
or resin is configurable in this aspect.

Also the name ' JSESSIONID' is configurable?

Maybe a better idea would be that someone from Apache Tomcat should push
to google with some standards tomcat implement in this respect so that
google change the algorithm and not punish with low ranking websites
powered by tomcat.

Any other suggestion?

Regards,
Marian Simpetru

 GOOGLE - This answer is for your question ! Thank you !

 Using URL-encoded sessions can damage your search engine placement

 To prevent abuse, search engines such as Google associate web content
with 
 a single URL, and penalize sites which have identical content
reachable 
 from multiple, unique URLs. Because a URL-encoded session is unique
per 
 visit, multiple visits by the same search engine bot will return
identical 
 content with different URLs. This is not an uncommon problem; a test 
 search for ;jsessionid in URLs returned around 79 million search
results.
 It's a security risk

 Because the session identifier is included in the URL, an attacker
could 
 potentially impersonate a victim by getting the victim to follow a 
 session-encoded URL to your site. If the victim logs in, the attacker
is 
 logged in as well - exposing any personal or confidential information
the 
 victim has access to. This can be mitigated somewhat by using short 
 timeouts on sessions, but that tends to annoy legitimate users.


Re: JSESSIONID and impact on google

2010-02-09 Thread Marian Simpetru
Thank you,

I guess session is created since a user could change preferred
language..  In a portal is basic stuff. Then you need session since page
one. We write JSR168 portlets on top of the Liferay portal ..

It's really an useful feature.

Thanks for your time, we look forward for tomcat 7 I guess a beta will
be released soon.

Marian



On Tue, 2010-02-09 at 14:50 +, Mark Thomas wrote:

 On 09/02/2010 14:31, Marian Simpetru wrote:
 
  Question is: Is there a way to configure tomcat to only use cookies (not
  append jsessionid to URL for cookie0less browsers). I've been told Jetty
  or resin is configurable in this aspect.
 
 There will be in Tomcat 7 onwards. Prior to that, using jsessionid in
 the URL was mandated by the spec.
 
  Also the name ' JSESSIONID' is configurable?
 
 Yes. See http://tomcat.apache.org/tomcat-6.0-doc/config/systemprops.html
 
  Maybe a better idea would be that someone from Apache Tomcat should push
  to google with some standards tomcat implement in this respect so that
  google change the algorithm and not punish with low ranking websites
  powered by tomcat.
 
 I don't think this is Google's problem. If a site doesn't need sessions,
 it shouldn't be using them. If the framework being used forces the use
 of sessions then the framework needs fixing.
 
  Any other suggestion?
 
 Don't use sessions.
 
 Mark
 
 
 
 -
 To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
 For additional commands, e-mail: users-h...@tomcat.apache.org