The best way to do this would be to maintain a cache of java objects in a separate thread that persists across connections. That way you wouldn't have to the price for serializing/deserializing the objects that you stored/retrieved from the db. Creating a persistant object store wouldn't be too difficult, but to do this, you would probably have to hack on the nsjavablend c-code, as there currently is no support for such a thing.
The big problem would be the management of the instances once they are created. What happens when, for example, a user accesses a page that creates some cached instances, but then for some reason, they walk away from the computer and come back several hours, days, or weeks later. You can't keep all those instances around, because eventually you will run out of memory. In addition you're creating a hole for a denial of service attack. To solve that problem, you could have some code that manages the instances such that objects that have been around for x amount of time are serialized and placed into the db, and then if the user comes back later, you can recreate the instances and carry on. Still you'll have the problem of filling your db with serialized instances of expired objects. You could then modify your instance management code such that serialized objects are eventually purged from the db, but then you need to code your pages so that the page redirects to the start of the page-flow sequence if the instances have been purged from the system. Overall, you're going to end up with writing alot of extra code to manage the created java instances. I imagine that if you want automatic mangement of persistant java objects between page requests, you would be better off using a J2EE compliant application server, as it would already have all of the session management features built into the server.