Win a copy of Murach's Java Programming this week in the Beginning Java forum!
  • Post Reply Bookmark Topic Watch Topic
  • New Topic

Need to logout twice for it to take effect  RSS feed

 
Michael Portman
Ranch Hand
Posts: 70
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hello all.

On my index servlet I've got the following code:



On my index servlet (forwards to index.jsp for EL stuff) ive got a link which logs you out by killing the session id, but I've got to click it twice for it to take effect. The link points to index.class as /index?logout=sessid. The index servlet forwards everything to index.jsp when visited. Any ideas?
 
Tim Moores
Saloon Keeper
Posts: 3755
78
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Why does the code take the user_id from a parameter? Presumably, each user is authenticated to log out herself only, so you can just call invalidate() on the user session and be done with it.

Also, it seems there is an instance variable called "nwg" that is not synchronized - that will lead to problems if more than a single user accesses the web app.

As an aside, I still think you should get in the habit of not overriding the service method.
 
Michael Portman
Ranch Hand
Posts: 70
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I tried using invalidate() but it didnt work, still need to click logout twice. I've got quite a few people testing my site while im developing it and they have told me everything runs quick and bug-free. It's the logout process thats not working as it should.

Also is it bad to use service()? Do I really need to use doPost and goGet? As my index servlet uses both GET and POST data.
 
Tim Moores
Saloon Keeper
Posts: 3755
78
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
As per the HTTP spec, GET and POST are used for different purposes. So any web app that treats them interchangeably is breaking the spec. That also effects the request's treatment by caches, proxies and similar HTTP infrastructure. Not to mention that URL parameters end up in places where one would not expect them, and where they could have adverse consequences - like log files, browser bookmarks, etc.

I've got quite a few people testing my site while im developing it and they have told me everything runs quick and bug-free.

Concurrency issues are unlikely to be found by manual testing. Deploying a web app that has lingering concurrency bugs, and hoping for the best, is bad practice.
 
Michael Portman
Ranch Hand
Posts: 70
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Tim Moores wrote:Concurrency issues are unlikely to be found by manual testing. Deploying a web app that has lingering concurrency bugs, and hoping for the best, is bad practice.


Ok, can you explain more about syncing and show me a working example of how to implement it? Forgive me but I'm relatively new to Java, I've only been using it for about a year tops. I'm coming from PHP.
 
Tim Moores
Saloon Keeper
Posts: 3755
78
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
That's a big subject. The basic tenet is that access to mutable shared state needs to be protected. Shared state includes all servlet instance variables and static variables, since all concurrent threads see them. If any of those are mutable, i.e. can change their values during the runtime of the web app, access to them needs to be guarded.

http://docs.oracle.com/javase/tutorial/essential/concurrency/ is the Java tutorial on concurrency. The chapter on Synchronization is certainly relevant, as are Concurrent Collections and Atomic Variables. There are other useful Java features as well, like declaring a variable volatile, and using ThreadLocal.

While using synchronization is one of the easiest to implement, it effectively kills concurrency, so one should use it sparingly - only for small blocks of code.
 
Dave Tolls
Ranch Hand
Posts: 2721
30
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Looking at the bit of code supplied:

There doesn't seem to be any reason at all for this to be an attribute of the servlet.

I would question why this servlet seems to be doing more than one thing.
Why not have a LogoutServlet to handle the logging out?
If nothing else it would save having to have a logout-specific parameter to indicate what it is you want to do with a particular request.
 
Michael Portman
Ranch Hand
Posts: 70
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Dave Tolls wrote:Looking at the bit of code supplied:

There doesn't seem to be any reason at all for this to be an attribute of the servlet.

I would question why this servlet seems to be doing more than one thing.
Why not have a LogoutServlet to handle the logging out?
If nothing else it would save having to have a logout-specific parameter to indicate what it is you want to do with a particular request.


because the nwg object gets forwarded to index.jsp within the request object, so index,jsp can access it's methods.
 
Michael Portman
Ranch Hand
Posts: 70
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
... the results of the nwg object are displayed on the index,jsp page via EL (JSTL)
 
Michael Portman
Ranch Hand
Posts: 70
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
...the index servlet works with the nwg object by setting vars, calling on other methods of different classes, processing forms, and doing other various tasks, then the nwg object is forwarded to index.jsp for the results to be displayed via EL (JSTL) calls.
 
Michael Portman
Ranch Hand
Posts: 70
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
...that code snippet i gave you is only the logout code. the index servlet has nearly 1000 lines of code. wish this forum had an edit post option lol.
 
Michael Portman
Ranch Hand
Posts: 70
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Dave Tolls wrote:Looking at the bit of code supplied:
Why not have a LogoutServlet to handle the logging out?
If nothing else it would save having to have a logout-specific parameter to indicate what it is you want to do with a particular request.


I made a logout servlet as you suggested and it works perfectly thanks!
 
Dave Tolls
Ranch Hand
Posts: 2721
30
  • Likes 1
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Michael Portman wrote:
because the nwg object gets forwarded to index.jsp within the request object, so index,jsp can access it's methods.


But that doesn't explain why it's an attribute of the servlet.
Adding it to the request makes it available to the JSP, but that doesn't mean it can't be a local variable.

Good that you got the logout to work!
Thousand line servlets are often a sign you're doing too much in a single place.
 
Bear Bibeault
Author and ninkuma
Marshal
Posts: 66041
140
IntelliJ IDE Java jQuery Mac Mac OS X
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Dave Tolls wrote:Thousand line servlets are often a sign you're doing too much in a single place.

Quoted for truth. A thousand-line anything is a sign that a refactor is in order.
 
Michael Portman
Ranch Hand
Posts: 70
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Dave Tolls wrote:
Michael Portman wrote:
because the nwg object gets forwarded to index.jsp within the request object, so index,jsp can access it's methods.


But that doesn't explain why it's an attribute of the servlet.
Adding it to the request makes it available to the JSP, but that doesn't mean it can't be a local variable.

Good that you got the logout to work!
Thousand line servlets are often a sign you're doing too much in a single place.


Sorry its just under 500 lines to be exact, it was an exaggeration, I got mixed up with another project im doing in PHP. If I didn't forward the nwg object to the index.jsp page by setting it as a request attribute then how would index.jsp get access to the nwg object?
 
Michael Portman
Ranch Hand
Posts: 70
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
... don't forget im quite new to java so theres probably other ways I can do things which im not aware of
 
Bear Bibeault
Author and ninkuma
Marshal
Posts: 66041
140
IntelliJ IDE Java jQuery Mac Mac OS X
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
500 lines is still way too much code, especially for a servlet. Servlets should serve as controllers. As such, they're pretty relegated to coordinating code written in other classes (such as model classes) rather than doing work themselves.
 
Michael Portman
Ranch Hand
Posts: 70
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Bear Bibeault wrote:500 lines is still way too much code, especially for a servlet. Servlets should serve as controllers. As such, they're pretty relegated to coordinating code written in other classes (such as model classes) rather than doing work themselves.


All the index servlet does is catch form data, put it into a HashMap and sends it to the relevant class (non-servlet) for further processing (EG register.class, profile.class, fileUploads.class, etc). It also handles analytics. The exact amount of lines in the index servlet is 423 as ive just checked.
 
Dave Tolls
Ranch Hand
Posts: 2721
30
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Michael Portman wrote: If I didn't forward the nwg object to the index.jsp page by setting it as a request attribute then how would index.jsp get access to the nwg object?


I'm not saying don't add it to the request, but:


this line implies that your servlet looks something like:

Now that attribute in line 2 is not needed there.
I don't see anything that means the earlier line couldn't simply be:

removing the need for the attribute.

The key to remember, especially as you are new to Java (and consequently Servlets) is to try and avoid giving them "state".  That is, avoid giving them attributes.
They operate in a multi-threaded environment, so lots of users can be hitting the servlet at the exact same time, meaning that any non-final mutable attribute (eg nwg in your code) can be changed between one thread and another.

To take your code in the original post, if two requests hit that code at the same time then user A would set the value of nwg to its value, and user B can then come along an set it to its value, before user A's thread has moved onto the forward.
So you can end up with the wrong value.
 
Michael Portman
Ranch Hand
Posts: 70
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Dave Tolls wrote:
Michael Portman wrote: If I didn't forward the nwg object to the index.jsp page by setting it as a request attribute then how would index.jsp get access to the nwg object?


I'm not saying don't add it to the request, but:


this line implies that your servlet looks something like:

Now that attribute in line 2 is not needed there.
I don't see anything that means the earlier line couldn't simply be:

removing the need for the attribute.

The key to remember, especially as you are new to Java (and consequently Servlets) is to try and avoid giving them "state".  That is, avoid giving them attributes.
They operate in a multi-threaded environment, so lots of users can be hitting the servlet at the exact same time, meaning that any non-final mutable attribute (eg nwg in your code) can be changed between one thread and another.

To take your code in the original post, if two requests hit that code at the same time then user A would set the value of nwg to its value, and user B can then come along an set it to its value, before user A's thread has moved onto the forward.
So you can end up with the wrong value.


Yeah I'll remove it as a member variable of index.class and define it within doPost() as you suggested. That better yeah?
 
Michael Portman
Ranch Hand
Posts: 70
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Also one question... when I user visits /index and theres no GET and POST data for doGet and doPost what will happen? Will they get a blank screen? This is why im using service()..
 
Dave Tolls
Ranch Hand
Posts: 2721
30
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
You need to think in terms of HTTP.

A request to your servlet is one of GET/POST/PUT/PATCH/DELETE.
You define which.
Which one it is determines which of doPost, doGet, doPatch, doPut, or doDelete is called.

Each one should handle tasks related to what it is.
So a GET should handle requests for data.
A POST should handle sending data to the server to be processed.
etc.

There's nothing to stop you mixing these things together, but that will end up with a confusing mess.

The service() method really should not be used.
 
Michael Portman
Ranch Hand
Posts: 70
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Dave Tolls wrote:You need to think in terms of HTTP.

A request to your servlet is one of GET/POST/PUT/PATCH/DELETE.
You define which.
Which one it is determines which of doPost, doGet, doPatch, doPut, or doDelete is called.

Each one should handle tasks related to what it is.
So a GET should handle requests for data.
A POST should handle sending data to the server to be processed.
etc.

There's nothing to stop you mixing these things together, but that will end up with a confusing mess.

The service() method really should not be used.


Ok Ill try and not use service then, just out of curiosity what is service meant for? Thanks
 
Michael Portman
Ranch Hand
Posts: 70
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
The problem ive got is if theres no GET and POST data when the user visits the index servlet how do I forward them to the index.jsp page without using service()? Because I tried separating the code into doGet and doPost but I keep getting a blank screen. Cheers.
 
Dave Tolls
Ranch Hand
Posts: 2721
30
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
If someone just types a URL into the browser it'll be a GET.

Since this is the index servlet then I would not expect the user to send a POST at all, so that would be a 405 (Method Not Allowed).

When the user logs in I would expect that to go to a LoginServlet, which would probably only have a doPost, to handle the login data.  Other ones would return a 405.
 
Did Steve tell you that? Fuh - Steve. Just look at this tiny ad:
Thoughts on deprecation in Java
https://coderanch.com/t/683016/java/Deprecation-Java
  • Post Reply Bookmark Topic Watch Topic
  • New Topic
Boost this thread!