I'm using conversation to use lot's of lazy loadings, so i still need the conversation running, and that's why i do need global transactions too.

I don't think you need global transactions for that. You need an extended persistent context indeed. However, the automatic database transactions with which Seam wraps JSF requests (confusingly named 'global' transactions) will not help with this. The automatic transactions only serve to isolate those requests from other transactions and to perform a bit of performance optimization by having only one tx encompassing multiple requests (if they are) instead of several transactions, each adding its own overhead.

All of this is in an long-running-conversation (entityManager is scoped to it), and even with an error i dont want to end it yet.

If by 'error' you meant a transaction rollback, be aware that rolling back a transaction does not cause a rollback of the Java object in the persistent context but leaves an inconsistent state. To quote from the JPA spec:

3.3.2 Transaction Rollback
For both transaction-scoped and extended persistence contexts, transaction rollback causes all pre-existing managed instances and removed instances to become detached. The instances’ state will be the state of the instances at the point at which the transaction was rolled back. Transaction rollback typically causes the persistence context to be in an inconsistent state at the point of rollback. In particular, the state of version attributes and generated state (e.g., generated primary keys) may be inconsistent. Instances that were formerly managed by the persistence context (including new instances that were made persistent in that transaction) may therefore not be reusable in the same manner as other detached objects—for example, they may fail when passed to the merge operation.

And about the transaction optimization. Queries to the database (from the lazy loading) needs a transaction? I always though that queries of any kind shouldnt need transactions cause it doesnt change the database anyway.

Several comments here: at a lower level, there is always a transaction. When people talk about 'no transaction' they mean no transaction initiated by the application or by the container. In the absence of any such declaration (forget about Seam and CMT for a moment), multiple SQL statements sent to the database will each be wrapped in its own transaction so in fact there is more overhead with this. A reason to use an explicit transaction (via the app or the container) encompassing multiple statements is isolation from other transactions, especially for applications requiring a higher isolation level than READ COMMITTED. Without this encompassing transaction, if you have multiple SQL statements populating a page, it is possible that the statements do not see the same data if other transactions make modifications during this time.  There is also less overhead in establishing the only transaction then in the previous case.

Lazy loading brings a different problem, however: multiple round-trips to the database. If you care about performance, then you want to avoid such a case and load the data in few queries with eager fetching. Extended persistence contexts are easy to abuse.

For performance, you can make further optimizations by declaring the queries read-only so the JPA provider (at least Hibernate) will not store the snapshot used to detect changes (normally, when entities are loaded, Hibernate automatically stores a copy of what has been loaded so it can later check if an entity has been changed and thus requires an update at flush time. If you know that you will not modify those entities, this will save memory in the persistence context.