xPDO's applicability in writing data to session instead of db?

I have an application I’m working on that allows users to save certain information without being logged in, using a $_SESSION map to hold the data. If the user decides he/she wants to be able to save this info permanently, they can register on the site and the data is written to custom tables via standard modx/xPDO methods. The question is: In concept, would xPDO’s methods be useful in processing data when in the "session context," or is it likely too much trouble, or just a conceptual mismatch? (Up ’til now, I’ve assumed write all custom methods (in the app’s main class) to process non-db data ... but it occurred to me that no matter where the data is stored, it is formed in the same way and has identical validation requirements.) Thanks for your thoughts ...

I think I understand what you’re trying to do.

The problem is that if the user logs in, the session would be replaced, and the data would be lost.

My solution would be to use the Login snippet’s pre & post hooks to put the data into hidden form fields and then save it to the database once logged in.

I’m not so focused on the transition from session to db --- I knew I’d be writing something to sync the session to the db (should a user beginning saving info to a session, then decide to register to gain "permanent" storage/extended data saving). The pointer on the login prehook is helpful though, as I was originally thinking I’d need to write a small plugin to trigger the sync. I’m simply wanting to gauge the idea of attempting to use xPDO (probably via extending it) to manipulate the session data.

I’m a little confused. MODX (which extends xPDO) uses a database table to store sessions already. All you need to do is make sure you log them in and I believe the session data will be preserved in the logged-in user’s session at that point. If not, you can easily capture the anonymous user session data before you log them in and write it back into their session once they are logged in.

@Jason:
Thanks for your response! What I was getting at was the writing of the data to a session map. Assume, for example, that the user never does register ... as they build their list of activities (the app is a trip planner for a tourism site), the data is only saved to the session map, not the custom db tables. To be honest, not too long after I posed the original question I began to think it was a questionable idea, given that PDO is all about db interactions. That said, I was originally thinking I might be able to take advantage of the mapping already done after building the app’s schema and the validation and processing functionalities already present in xPDO.

I’m doing something similar, with users ’shortlisting’ items which are held in $_SESSION with the option to login and save the list permanently. I only hold the necessary object ids in session and use xPDO to grab related data from the database.

It really depends on your setup: What does your session structure look like? And which xPDO methods did you intend to use?