Bellow are some basic information about OR mappers and random thoughts.
The ORM are not kind of Object Oriented database view of relation database, but they share some common points with OO databases (Objects, criteria queries, ...).
Most ORM mappers differentiate between
components (value objects) and
entities. Entity always has a constant id, in relational DB this is the primary key column(s). Object identity sometimes uses the primary key as object identity, but this is dangerous, because it may not be known until the new entity is persisted to database.
Object identity is bound to persistence context (unit of work, transaction) which contains the first level cache of ORM. It means that within the same persistence context the same object instance is always returned. But if the persistence context is closed or object is removed from persistence context, the object identity is no longer guarantied.
When starting on new project the objects first seems to be better solution, but it is good to talk to database specialist about the mapping.
The unit of work (transaction) does the first level cache.
Second level cache is not the best solution, tune the queries first. Not all queries will benefit from second level cache (data that changes very often or data that are mission critical should not be cached at all). The caches can be quite complicated when they are synchronized across the cluster and transactions or when the DB is accessed by other application simultaneously.
Query caches are not usually that efficient, caches of entities and relations are better.
Stored procedures are the fastest way to get data. ORM has limited support for stored procedures and it is rarely used. They do not play well with ORM. Stored procedure are very good for batch jobs, this is a place where ORM failed.