Hi all,

I'm working on a php CLI crawler/parser that uses Doctrine ORM. I want to 
log/save data about all php errors and/or exceptions that occur during 
execution of the script to their own tables in the same database for later 
inspection.

However, some non-fatal PHP errors might occur during the execution of some 
database/doctrine related code, which might cause either:
- The error-logging queries to be executed within the boundaries of an open 
transaction (In case of explicit transaction demarcation).
- The error-logging queries will be aggregated and executed within the 
current unit of work, along with other queries (In case of implicit 
transaction demarcation).

This might introduce problems (or at least complexities), since maintenance 
queries (logging errors) are executed within the boundaries of other 
business level transactions.

Here are the paths that I'm investigating. Which do you recommend?

1. Using two separate Entity Managers, one for the regular application 
code, and the other for logging.
This seems like the obvious solution, but I'm concerned about the memory 
footprint, and whether there's a more efficient solution.

2. A signle Entity manager, while having application code executed within 
the Unit of work (implicit transaction demarcation), and the logging code 
executed as DQL or SQL queries.
I think this would actually work fine, and there would be no overlap 
between the queries/transactions, but once I begin to use explicit 
transaction demarcation, problems might happen again.

3. Letting logging code have their own nested transactions within other 
open transactions.
However, a failure in the logging/internal transactions will cause the main 
transactions to fail. There's ever one open transaction per connection (as 
per doctrine's docs).

4. A single Entity Manager with two separate units of work.
I guess there's nothing like "Two units of work at the same time for a 
single Entity Manager".

5. A single Entity Manager with two connections.
Guess there's nothing like that either.

6. Caching and flushing log entries to points in code that I'm sure there's 
no other transaction running.
This might work but will introduce code-level complexities.

I think the options that might work are either 1, or 6. Though I would love 
to hear about a more efficient solution.
Any suggestions?

Thanks
Hany

-- 
You received this message because you are subscribed to the Google Groups 
"doctrine-user" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to [email protected].
To post to this group, send email to [email protected].
Visit this group at http://groups.google.com/group/doctrine-user.
For more options, visit https://groups.google.com/d/optout.

Reply via email to