You are not limited to these two options, really.
First, let me clarify some confusion.
Every session has an identifier used to match a particular browser with a set of data being stored on the server. That identifier has to be stored on a user's device somehow - using cookies or trans_sid. Note that the
Another difference is that some people don't accept cookies. The session solution would work anywhere.
You have ways to control the session expiration time - look at how do the social network sites remember you for months. The session lifetime consists of two parts:
- for how long does a user device remember the session, i.e. store the session ID and use it for authentication; and
- for how long does the server store the associated data, i.e. is able to match the session ID provided with a set of data generated and stored during a corresponding visit
If you're using cookies to store the session id then increase their lifetime - just like you said, for a month or so. Then configure the server auto-cleanup process to keep sessions for that month or so.
If you're passing the ID in the URL then it will be stored for as long as the user has that URL, but again, the server configuration will have to be adjusted accordingly as well.
As suggested above, a good idea would be to associate the cart to an actual user account or email, that way if a session expires or gets lost (a user has cleaned the cookies or reinstalled the browser or just logged on from a different device) you can always restart it using the customer's email or username and preload the data.
Another point about cookies is that their contents are viewable by the users, e.g. if you store some tracking information there, it may be viewed or altered by the users.
Either way, it feels like the question belongs to Stackoverflow