If the other page is on the same domain, then any information stored in cookies can be accessed by both of them, and doesn't need to be appended to the link. Typically if you're using JSPs, the servlet container will automagically manage sessions for you (based on a cookie behind the scenes) - so you can set attributes on the session in one page, and then read them from another. See for example this Sun tutorial on storing client state in servlets.
Bear in mind though that this would need to happen on the server-side, so if it was something that needed to be done exactly when the user clicked on the link (such as recording the time they clicked), then this could not be done by pure JSP session logic. You'd need to provide some kind of cookie-based logic yourself.
And if the target page is on another domain altogether, then appending attributes to the request is the only way to communicate this information. I'm not sure what your objection is to doing this, whether it's technical or otherwise; it's a very common technique and one that works well. There's a variety of methods to apply "cosmetic" tweaks to the process, such as a landing page to read the information from the URL, put it in the client's session on that site, and then replace the URL with a "cleaner" version (i.e. one with all the added parameters removed). Alternatively, POSTing a request will mean the attributes don't appear in the actual URL itself, and would make sense if the link represents some kind of action or non-repeatable (i.e. non-bookmarkable) state.
What problem exactly are you having with putting attributes in the URL?