I had seen that post, which is what prompted me to post my own.  I am 
trying to better understand how multiple threads should/can share objects. 
 I don't want to go the route of "each call creates its own set of 
objects", if there's a more efficient way to do things.

As an example, consider the AdWordsServices class, which is new (to me). 
 The migration guide says "The AdWordsServices object is fairly heavyweight 
and should be instantiated once and reused as much as possible."  It is not 
thread-safe, but it doesn't retain any state.  My conclusion is that if I 
make a singleton AdWordsServices object for use throughout my code, as long 
as I make sure no two threads are calling adWordsServices.get at the same 
time, that should be more efficient than creating a new one every time I 
need to make an AdWords API call.  In order to achieve thread safety, I 
will probably wrap the AdWordsServices object inside my own singleton 
object, with a synchronized "get" method that passes through to the wrapped 
AdWordsServices object.  That's an example of a best practice that I'm 
looking for.

As for the OAuth2 credential, I have managed to create a valid one from a 
saved refresh token, by building the credential and then calling 
credential.refreshToken().  I'm still trying to figure out whether I need 
to do this refresh step or if it would happen automatically, and also 
whether calling refreshToken() is going to invalidate any AdWordsSession(s) 
that are currently using the credential before it got refreshed.  I'm going 
to write some tests, and once I understand the credentials, tokens, and 
AdWordsSessions better, I will be able to come up with a coding strategy 
that fits my use case (long-lived services, all with the "same" login). 
 But if there are examples already that match my use case, it will be a big 
time-saver and also make it more likely that I don't misunderstand how 
things work, or come up with a flawed solution.

On Tuesday, October 9, 2012 1:42:49 PM UTC-4, Oliver wrote:
>
> You will need to persist the refresh token and account ID so your services 
> can resume on their own in case of a restart.  You can ceate valid 
> AdwordsSession and AdwordsServices on the fly if you have these two fields.
>
> Also, this might be of help:
> https://groups.google.com/forum/?fromgroups=#!topic/adwords-api/zf0slvrjkMs
>
> Oliver
>
> On Tuesday, October 9, 2012 5:08:03 PM UTC+1, j.e.frank wrote:
>>
>> I am trying to migrate to v201209 from v201109.  I have several 
>> long-lived services that use the AdWords API on behalf of my MCC account, 
>> for example to run reports, to get ad details, and so forth.  I'm trying to 
>> understand how I should be using the new session/service objects, such that 
>> more than one thing can be happening at once, but that I don't create a new 
>> session or service object when I don't need to, and also that I use my 
>> OAuth2 tokens appropriately (refresh if necessary but not every time I need 
>> to make a call).  I've seen several pieces of example code, but they are 
>> self-contained so they always get a new session, new service object, 
>> refresh the OAuth token, etc. Are there any examples more suitable for 
>> long-running services that will be invoked from time to time?
>
>

-- 
=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~
Also find us on our blog and discussion group:
http://adwordsapi.blogspot.com
http://groups.google.com/group/adwords-api
=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~

You received this message because you are subscribed to the Google
Groups "AdWords API Forum" group.
To post to this group, send email to [email protected]
To unsubscribe from this group, send email to
[email protected]
For more options, visit this group at
http://groups.google.com/group/adwords-api?hl=en

Reply via email to