You "detach" from a persistency mechanism. Usually that means at its base, a
JDBC Connection. Normal ORM for EJB - and JDO retrieves the data into persistent beans, but leaves them attached. Because they're attached, you don't have to explicitly reference their persistence mechanism - it's, well, it's attached. To the persistent object. Using the appropriate methods, a persistency mechanism can save the time and effect of establishing a database connection to the object, by drawing on that attachment to retrieve the connection info.
However, java.sql.Connection - not to mention various other popular constructs - is not a serializable class, it's an Interface. So if you have a need to store or copy the persistent object somewhere outside its current context, you have to detach the non-Serializable stuff. You also do this if you want to be able to disconnect the persistence manager and return its resources to the pool. EJB3 calls the PM something different, but same idea.
If you're attempting to capture a set of objects related to each other and detach them, you may have to do something to ensure that all the dependent objects have been populated before detaching. Otherwise they'll come back as NULL later, since without the persister connection it's impossible to get anything more from the database.
There's also another pitfall. If you're re-attaching, not all ORM systems literally re-attach. I ran into a lot of trouble using JDO on that account, because the returned item(s) from a re-attach weren't the same items that I'd passed into the re-attach method call. They were cloned copies of those items, except that the copies had persistency and the original items did not.