Is a big servlet ok?


Web tier: servlets, JSP, Web frameworks: Is a big servlet ok?

  1. Is a big servlet ok? (9 messages)

    Hi all. Without giving much info about what my servlet actually does, I was wondering, is it normal to have a servlet that's 1000 lines (with a decent amount of commenting)? I've been doing some web development for quite a few months but don't really have anyone to ask these questions, and want to make sure I'm not doing crazy things that are unheard of.

    Threaded Messages (9)

  2. A big servlet is not ok, IMO[ Go to top ]

    I'm thinking a big servlet is not so ok. (We have some big servlets where I work, and I think it's a bad move.)

    You should get into (well-designed) POJOs as quickly as possible, imo, and the servlet should just be a thin wrapper, adapting your POJOs/business logic to the web interface.

    If you want to re-use that logic outside of a web interface, what are you going to do? Instantiate the servlet object w/some fake ServletRequest/ServletResponse? Cut-n-paste the code?

    This is a bit of a sort point w/me, as you might be able to tell. All this slick magazine article emphasis on "Model 2 Architecture" missed the point: do the logic first, put the interface on afterwards. Logic should exist in deep space, just a bunch of plain objects floating around. Later, you can access that logic from a servlet, with a small-enough piece of code to justify the "-let" suffix.


  3. interesting[ Go to top ]

    I like your response John. Let me explain slightly more now.

    The servlet checks the session for some different variables. Basically, all the servlet does is query a database and gets rows of items. However, depending on what variables exist in the session, different queries have to be used. Also, depending on what variables are present, the queries have to be pieced together with a string buffer to run the correct query. The queries are quite large - many lines.

    Since I'm relatively new to all this, I get scared I'm not doing things smartly, so they will be clean and future safe.

    i like the idea of using java objects. I think something that I have been worrying about is creating threadsafe code. Say i make a java class that creates and runs my queries, and returns the result set to the servlet. From my reading, it seems servlets have to be coded threadsafe (no class variables) because multiple instances will be created. What about a plain old java class? Do i need to worry about this being threadsafe?

    Thanks for the help!
  4. Is a big servlet ok?[ Go to top ]

    while having business code in servlet rather than JSP is the right idea..especialy in the MVC pattern.

    we are refactoring our Action Classes(Struts) by removing code in the servelts and makin them in helper classes so we can better JUNIT test!
  5. im also using struts[ Go to top ]

    I'm also using struts.
  6. Is a big servlet ok?[ Go to top ]

    You are right to worry about thread safety. You may have threading problems if you keep read-write instance variables in your servlet object. However, if these are read only immutable objects that encapsulate some business logic, you can initialize these objects at the servlet initialization time. Youcan then use them from all requests without having to worry about threading problems.

    On the other hand, if these are mutable objects then depending on the scope of the object you can either create one per request and store it in a ThreadLocal, or create one per session and store it in the session.
  7. Is a big servlet ok?[ Go to top ]

    Or sling 'em around on the stack, as parameters to method calls.

    Until your list of formal parameters gets too long (say, > 5 parameters). At which point, you make a new object.

    ThreadLocal and session are just glorified forms of global variables, with all the heartache that entails ("holy cow, which method changed the data?"). Useful in their place, but not what I would consider a first solution.


  8. scenario[ Go to top ]

    Ok. So, I don't know a ton about the term immutable objects, although I just researched them a little.

    Would this scneario be thread safe and the right way to do things?

    Say there's a servlet. Inside the action we want to somehow get a result set from a database.


    String search = session.getAtrtribute("search");
    if (search != null){
        GetResultsClass resultsObj = new GetResultsClass(search,....any other info we need to pass);

    //lets say RunQuery on the object
    //will return the full resultset
    resultset = resultsObj.RunQuery;

    //stick the results in the session
    session.setAttribute("resultSet", resultset);

    forward to the jsp page to display results.... The resultObj should be killed and cleaned up once the servlet is finished.

    Let's say the GetResultsClass is just a java class that takes the parameters in its constructor, sets its class variables to what is passed in, then has a function that can be called on the object (Runquery) that will then run the query and return a resultSet.
    Is this immutable? Is this threadsafe? If it has some class variables that can be set inside the object, does this mean that it is not threadsafe? If more than one copy of this servlet is running, will each get its own GetResultsClass object (therefore threadsafe), or will they be sharing one object and then can overwrite the object's class variables, etc....

    Thanks again for the help guys, it's really appreciated!
  9. scenario[ Go to top ]

    An immutable object is a read-only object. It gets initialized at creation and its value never changes afterwards. That makes them thread-safe by nature because there is no chance of race conditions.

    Regarding your scenario, I don't think you should be storing this result set in the session. If you just need to display this result set in one jsp then storing it in the session is an overkill. It means that this object will remain in memory as long as the session (as opposed to the request) is alive. I'm not very familiar with the use of vanilla jsp so I can't give you a concrete suggestion here, but in general you should return that result set through the response object not through the session. You only store data in the session if you need to keep it accross multiple requests in the same session.

    Regarding thread-safety, this code looks thread-safe because you don't access any instance variables from multiple threads. You create a new GetResultsClass instance for each request (that is, for each thread). This is similar to what John was suggesting.
  10. scenario[ Go to top ]

    As Mohamed suggests, don't store in session. This is a perfect case for storing the result in the request, as in:

    request.setAttribute( "resultSet", resultSet);

    Even if GetResultsClass has instance data members, it's ok, it's nicely encapsulated. A different, simultaneous request running through this servlet will instantiate its own instance of GetResultsClass w/no problem.