<div dir="ltr">Jay, <div><br></div><div><span style="font-family:arial,sans-serif;font-size:13px">The session object will be commit()'d after the session.begin() context manager exits, which will cause the aforementioned BEGIN; INSERT; COMMIT; transaction to be executed against the server for each event record.</span><br style="font-family:arial,sans-serif;font-size:13px">

</div><div><span style="font-family:arial,sans-serif;font-size:13px"><br></span></div><div><span style="font-family:arial,sans-serif;font-size:13px">It is a just half of problem. We should use SQL Bulk Inserts as well. </span></div>
<div><span style="font-family:arial,sans-serif;font-size:13px">And we should mention that declarative_base won't make this work for us transparent. (Even if we make all in one transactions there will be N Inserts). </span></div>
<div><br></div><div><br></div><div>Best regards,</div><div>Boris Pavlovic</div><div><br></div></div><div class="gmail_extra"><br><br><div class="gmail_quote">On Sat, Dec 21, 2013 at 10:57 AM, Jay Pipes <span dir="ltr"><<a href="mailto:jaypipes@gmail.com" target="_blank">jaypipes@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="im">On 12/20/2013 04:43 PM, Julien Danjou wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
On Fri, Dec 20 2013, Herndon, John Luke wrote:<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
I think there is probably a tolerance for duplicates but you’re right,<br>
missing a notification is unacceptable. Can anyone weigh in on how big of a<br>
deal duplicates are for meters? Duplicates aren’t really unique to the<br>
batching approach, though. If a consumer dies after it’s inserted a message<br>
into the data store but before the message is acked, the message will be<br>
requeued and handled by another consumer resulting in a duplicate.<br>
</blockquote>
<br>
Duplicates can be a problem for metering, as if you see twice the same<br>
event it's possible you will think it happened twice.<br>
<br>
As for event storage, it won't be a problem if you use a good storage<br>
driver that can have unique constraint; you'll just drop it and log the<br>
fact that this should not have happened, or something like that.<br>
</blockquote>
<br></div>
The above brings up a point related to the implementation of the existing SQL driver code that will need to be re-thought with the introduction of batch notification processing.<br>
<br>
Currently, the SQL driver's record_events() method [1] is written in a way that forces a new INSERT transaction for every record supplied to the method. If the record_events() method is called with 10K events, then 10K BEGIN; INSERT ...; COMMIT; transactions are executed against the server.<br>

<br>
Suffice to say, this isn't efficient. :)<br>
<br>
Ostensibly, from looking at the code, the reason that this approach was taken was to allow for the collection of duplicate event IDs, and return those duplicate event IDs to the caller.<br>
<br>
Because of this code:<br>
<br>
        for event_model in event_models:<br>
            event = None<br>
            try:<br>
                with session.begin():<br>
                    event = self._record_event(session, event_model)<br>
            except dbexc.DBDuplicateEntry:<br>
                problem_events.append((api_<u></u>models.Event.DUPLICATE,<br>
                                       event_model))<br>
<br>
The session object will be commit()'d after the session.begin() context manager exits, which will cause the aforementioned BEGIN; INSERT; COMMIT; transaction to be executed against the server for each event record.<br>

<br>
If we want to actually take advantage of the performance benefits of batching notification messages, the above code will need to be rewritten so that a single transaction is executed against the database for the entire batch of events.<br>

<br>
Best,<br>
-jay<br>
<br>
[1] <a href="https://github.com/openstack/ceilometer/blob/master/ceilometer/storage/impl_sqlalchemy.py#L932" target="_blank">https://github.com/openstack/<u></u>ceilometer/blob/master/<u></u>ceilometer/storage/impl_<u></u>sqlalchemy.py#L932</a><div class="HOEnZb">
<div class="h5"><br>
<br>
<br>
______________________________<u></u>_________________<br>
OpenStack-dev mailing list<br>
<a href="mailto:OpenStack-dev@lists.openstack.org" target="_blank">OpenStack-dev@lists.openstack.<u></u>org</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/<u></u>cgi-bin/mailman/listinfo/<u></u>openstack-dev</a><br>
</div></div></blockquote></div><br></div>