tomee-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Mark Struberg <strub...@yahoo.de>
Subject Re: JDBC Transactions vs EJBs and @TransactionAttribute(...) and more...
Date Fri, 17 Oct 2014 19:08:18 GMT
Hi Lars-Fredrik!

With pure JPA you could kind of 'emulate' JTA. At least in a poor mans way without 100% guarantee.

iterate over all open connections and em.flush() them. This is actually the part where either
the operation blows up or all is fine.
Then after that in a second pass you loop over the open EntityManagers again and do your em.getTransaction().commit().
This really works most of the times. Of course not 100%. If you need 100% just use JTA.

I case you are not sure I suggest you use DeltaSpike @Transactional. It provides both implementations
and you could simple switch between those two.

If you know that you 100% always will use JTA and don't need @RequestScoped EntityManagers
(which is really cool for JSF apps, because it enables lazy loading in the render response
phase) then you can also use EJBs.


LieGrue,
strub




> On Friday, 17 October 2014, 8:38, Lars-Fredrik Smedberg <itsmeden@gmail.com> wrote:
> > haha... true true.... will direct it to them
> 
> /LF
> 
> On Fri, Oct 17, 2014 at 8:22 AM, Romain Manni-Bucau <
> rmannibucau@tomitribe.com> wrote:
> 
>>  purequery questions are for IBMs ;)
>>  Romain Manni-Bucau
>>  Twitter: @rmannibucau
>>  Blog: http://rmannibucau.wordpress.com/
>>  LinkedIn: http://fr.linkedin.com/in/rmannibucau
>>  Github: https://github.com/rmannibucau
>> 
>> 
>> 
>>  2014-10-17 8:19 GMT+02:00 Lars-Fredrik Smedberg <itsmeden@gmail.com>:
>>  > @Romain
>>  >
>>  > Is there something similar to checkDs that I can do when using EJBs,
>>  > Container Managed tx and PureQuery (which in turn gets connections 
> from
>>  an
>>  > injected datasource and fires queries...). That is checkDs without 
> JPA?
>>  >
>>  > Regards
>>  > LF
>>  >
>>  > On Thu, Oct 16, 2014 at 3:48 PM, Lars-Fredrik Smedberg <
>>  itsmeden@gmail.com>
>>  > wrote:
>>  >
>>  >> True haha... will have a look at it... I really want to learn the
>>  details
>>  >> (and in my case have to due to some design we are in the middle 
> of)...
>>  >>
>>  >> Anyway... thanks for all help, preciate it!
>>  >>
>>  >> /LF
>>  >>
>>  >> On Thu, Oct 16, 2014 at 3:42 PM, Romain Manni-Bucau <
>>  >> rmannibucau@tomitribe.com> wrote:
>>  >>
>>  >>> hehe you are curious, read
>>  >>> org.apache.openjpa.kernel.BrokerImpl#beforeCompletion. It 
> basically
>>  >>> check all state of the entities
>>  >>> Romain Manni-Bucau
>>  >>> Twitter: @rmannibucau
>>  >>> Blog: http://rmannibucau.wordpress.com/
>>  >>> LinkedIn: http://fr.linkedin.com/in/rmannibucau
>>  >>> Github: https://github.com/rmannibucau
>>  >>>
>>  >>>
>>  >>>
>>  >>> 2014-10-16 15:38 GMT+02:00 Lars-Fredrik Smedberg 
> <itsmeden@gmail.com>:
>>  >>> > Thanks for the answer
>>  >>> >
>>  >>> > What exactly is involved in a checkDs1() call?
>>  >>> >
>>  >>> > Regards
>>  >>> > LF
>>  >>> >
>>  >>> > On Thu, Oct 16, 2014 at 3:33 PM, Romain Manni-Bucau <
>>  >>> > rmannibucau@tomitribe.com> wrote:
>>  >>> >
>>  >>> >> 2014-10-16 15:01 GMT+02:00 Lars-Fredrik Smedberg <
>>  itsmeden@gmail.com>:
>>  >>> >> > Thanks again, see below.
>>  >>> >> >
>>  >>> >> > On Thu, Oct 16, 2014 at 2:05 PM, Romain 
> Manni-Bucau <
>>  >>> >> > rmannibucau@tomitribe.com> wrote:
>>  >>> >> >
>>  >>> >> >> 2014-10-16 13:20 GMT+02:00 Lars-Fredrik 
> Smedberg <
>>  >>> itsmeden@gmail.com>:
>>  >>> >> >> > Just one more thing I forgot to put in 
> the other mail
>>  >>> >> >> >
>>  >>> >> >> > With "Depend, using 
> ManagedConnection it will be green but it
>>  >>> will not
>>  >>> >> >> do what
>>  >>> >> >> > you expect." you mean that I will 
> think it runs in a tx but its
>>  >>> not
>>  >>> >> and
>>  >>> >> >> in
>>  >>> >> >> > case of failure I might get 
> inconsistency?
>>  >>> >> >> >
>>  >>> >> >>
>>  >>> >> >> right, if datasource2.commit() fails but 
> ds1.commit() passed then
>>  >>> you
>>  >>> >> >> are not consistent. Of course with jpa it is 
> not that impacting
>>  >>> since
>>  >>> >> >>
>>  >>> >> >
>>  >>> >> > Could you please explain how jpa tries to solve 
> this? I guess it
>>  >>> will not
>>  >>> >> > completely remove the consisitency risk but only 
> lower the risk?
>>  >>> >> >
>>  >>> >>
>>  >>> >> It doesn't but it limits it in practise. It 
> basically do a check
>>  >>> >> before calling commit. All checks pass before commit:
>>  >>> >>
>>  >>> >> checkDs1();
>>  >>> >> checkDs2();
>>  >>> >> commitDs1();
>>  >>> >> commitDs2();
>>  >>> >>
>>  >>> >> so it avoids half of the ds2 commit fails but not 
> ds1.
>>  >>> >>
>>  >>> >> >
>>  >>> >> >> the provider checks it before committing.
>>  >>> >> >>
>>  >>> >> >>
>>  >>> >> > So I guess in our case: non xa datasources with 
> multiple
>>  connections
>>  >>> >> within
>>  >>> >> > a transaction we are not guaranteed consistency?
>>  >>> >> >
>>  >>> >>
>>  >>> >> Yep
>>  >>> >>
>>  >>> >> > I see also that some db vendors (MQ SQL) has 
> some optimization so
>>  >>> >> > transactions involving multiple connections from 
> different
>>  >>> datasources
>>  >>> >> but
>>  >>> >> > from the same db is not promoted to a 
> distributed tx
>>  >>> >> >
>>  >>> >> > => Is that only vendor specific or is that 
> according to spec to
>>  not
>>  >>> >> promote
>>  >>> >> > it in certain situations?
>>  >>> >> >
>>  >>> >>
>>  >>> >> vendor
>>  >>> >>
>>  >>> >> >
>>  >>> >> > resource = datasource != underlying db (without 
> using openejb
>>  >>> >> >> aliases). Each datasource has its own pool 
> of connection and then
>>  >>> its
>>  >>> >> >> own JTA integration (different Xid).
>>  >>> >> >>
>>  >>> >> >> > Regards
>>  >>> >> >> > LF
>>  >>> >> >> >
>>  >>> >> >> > On Thu, Oct 16, 2014 at 12:59 PM, 
> Romain Manni-Bucau <
>>  >>> >> >> > rmannibucau@tomitribe.com> wrote:
>>  >>> >> >> >
>>  >>> >> >> >> Well I don't know websphere 
> enough to answer to the related
>>  >>> question
>>  >>> >> >> >>
>>  >>> >> >> >>
>>  >>> >> >> >> 2014-10-16 12:55 GMT+02:00 
> Lars-Fredrik Smedberg <
>>  >>> itsmeden@gmail.com
>>  >>> >> >:
>>  >>> >> >> >> > Thanks Romain, please see if 
> you can help me on the follow
>>  up
>>  >>> >> below?
>>  >>> >> >> >> >
>>  >>> >> >> >> >
>>  >>> >> >> >> > On Thu, Oct 16, 2014 at 9:33 
> AM, Romain Manni-Bucau <
>>  >>> >> >> >> rmannibucau@gmail.com>
>>  >>> >> >> >> > wrote:
>>  >>> >> >> >> >
>>  >>> >> >> >> >> 2014-10-16 9:31 GMT+02:00 
> Lars-Fredrik Smedberg <
>>  >>> >> itsmeden@gmail.com
>>  >>> >> >> >:
>>  >>> >> >> >> >> > @Romain
>>  >>> >> >> >> >> >
>>  >>> >> >> >> >> > I can see in the 
> ManagedConnection code that the reused
>>  >>> >> Connection
>>  >>> >> >> is
>>  >>> >> >> >> per
>>  >>> >> >> >> >> > Transaction per 
> DataSource.
>>  >>> >> >> >> >> >
>>  >>> >> >> >> >> > So if I use 2 x 
> DataSource (pointing to the same DB but
>>  with
>>  >>> >> >> different
>>  >>> >> >> >> >> > properties set) I 
> will within a transaction use 2
>>  >>> connections,
>>  >>> >> >> >> correct?
>>  >>> >> >> >> >> >
>>  >>> >> >> >> >> yep
>>  >>> >> >> >> >>
>>  >>> >> >> >> >> > Will this result in a 
> distributed transaction?
>>  >>> >> >> >> >> >
>>  >>> >> >> >> >>
>>  >>> >> >> >> >> No, this ManagedConnection 
> is to get JTA integration
>>  "locally"
>>  >>> >> (ie we
>>  >>> >> >> >> >> integrate locally with XA 
> hooks but it is not distributed).
>>  >>> For
>>  >>> >> that
>>  >>> >> >> >> >> you have to use a really 
> XA datasource.
>>  >>> >> >> >> >>
>>  >>> >> >> >> >
>>  >>> >> >> >> > We use WebSphere in 
> test/production and the driver included
>>  in
>>  >>> >> >> >> db2jcc4.jar.
>>  >>> >> >> >> >
>>  >>> >> >> >> > As far as I understand from 
> the documentation if the type
>>  >>> >> attribute of
>>  >>> >> >> >> the
>>  >>> >> >> >> > datasource element in the 
> configuration is not set it will
>>  >>> search
>>  >>> >> the
>>  >>> >> >> >> > driver jar for datasources in 
> the following order:
>>  >>> >> >> >> >
>>  >>> >> >> >> > 
> javax.sql.ConnectionPoolDataSource
>>  >>> >> >> >> > javax.sql.DataSource
>>  >>> >> >> >> > javax.sql.XADataSource
>>  >>> >> >> >> >
>>  >>> >> >> >> > In our testconfiguration we do 
> not specify the type
>>  attribute
>>  >>> so I
>>  >>> >> >> assume
>>  >>> >> >> >> > we are NOT using XA 
> datasource. correct?
>>  >>> >> >> >> >
>>  >>> >> >> >> > So some questions on the 
> above:
>>  >>> >> >> >> >
>>  >>> >> >> >> > 1. In what cases will I not 
> need a distributed tx?
>>  >>> >> >> >>
>>  >>> >> >> >> You don't need it either when 
> you have a single or totally
>>  >>> >> decorelated
>>  >>> >> >> >> resources (datasource for instane) 
> or when you want
>>  performances
>>  >>> (XA
>>  >>> >> >> >> is slow) and can accept some manual 
> operations to fix
>>  >>> inconsistency
>>  >>> >> if
>>  >>> >> >> >> it happens (should be rare)
>>  >>> >> >> >>
>>  >>> >> >> >> > a) A tx with 1 connection to a 
> DB? No!
>>  >>> >> >> >> > b) A tx with 2 connections 
> (from seperate datasources)
>>  >>> connected to
>>  >>> >> >> the
>>  >>> >> >> >> > same DB? <== ??
>>  >>> >> >> >> > c) A tx with 2 connections 
> (from seperate datasources)
>>  >>> connected to
>>  >>> >> >> >> > different DBs? Yes!
>>  >>> >> >> >> > d) A tx with 1 connection to a 
> DB and e.g. JMS? Yes!
>>  >>> >> >> >> >
>>  >>> >> >> >> > 2. If I have a scenario that 
> requires a distributed and the
>>  >>> >> datasource
>>  >>> >> >> >> that
>>  >>> >> >> >> > is used is NOT an XA 
> datasource what will happen? Exception?
>>  >>> >> >> >> >
>>  >>> >> >> >>
>>  >>> >> >> >> Depend, using ManagedConnection it 
> will be green but it will
>>  not
>>  >>> do
>>  >>> >> >> >> what you expect.
>>  >>> >> >> >>
>>  >>> >> >> >> > Thanks
>>  >>> >> >> >> >
>>  >>> >> >> >> > Regards
>>  >>> >> >> >> > Lars-Fredrik
>>  >>> >> >> >> >
>>  >>> >> >> >> >
>>  >>> >> >> >> >
>>  >>> >> >> >> >>
>>  >>> >> >> >> >> > Regards
>>  >>> >> >> >> >> > LF
>>  >>> >> >> >> >> >
>>  >>> >> >> >> >> > On Wed, Oct 15, 2014 
> at 8:48 AM, Romain Manni-Bucau <
>>  >>> >> >> >> >> rmannibucau@gmail.com>
>>  >>> >> >> >> >> > wrote:
>>  >>> >> >> >> >> >
>>  >>> >> >> >> >> >> Hi
>>  >>> >> >> >> >> >>
>>  >>> >> >> >> >> >> that's the 
> global idea yes
>>  >>> >> >> >> >> >>
>>  >>> >> >> >> >> >> about transaction 
> manager:
>>  >>> >> >> >> >> >>
>>  >>> >> >> >> >> >>
>>  >>> >> >> >> >>
>>  >>> >> >> >>
>>  >>> >> >>
>>  >>> >>
>>  >>>
>> 
> http://grepcode.com/file/repo1.maven.org/maven2/org.apache.geronimo.components/geronimo-transaction/3.1.1/org/apache/geronimo/transaction/manager/TransactionManagerImpl.java#TransactionManagerImpl
>>  >>> >> >> >> >> >> is th eone
>>  >>> >> >> >> >> >>
>>  >>> >> >> >> >> >> idea is simple: 
> invoke registered hooks when needed and
>>  >>> just
>>  >>> >> >> manage
>>  >>> >> >> >> >> >> the lifecycle 
> then EJB containers start/stop these hooks
>>  >>> >> calling
>>  >>> >> >> the
>>  >>> >> >> >> >> >> tx mgr (look 
> SingletonContainer hierarchy in
>>  openejb-core
>>  >>> for
>>  >>> >> >> >> >> >> instance)
>>  >>> >> >> >> >> >>
>>  >>> >> >> >> >> >>
>>  >>> >> >> >> >> >> Romain 
> Manni-Bucau
>>  >>> >> >> >> >> >> @rmannibucau
>>  >>> >> >> >> >> >> 
> http://www.tomitribe.com
>>  >>> >> >> >> >> >> 
> http://rmannibucau.wordpress.com
>>  >>> >> >> >> >> >> 
> https://github.com/rmannibucau
>>  >>> >> >> >> >> >>
>>  >>> >> >> >> >> >>
>>  >>> >> >> >> >> >> 2014-10-15 1:19 
> GMT+02:00 Lars-Fredrik Smedberg <
>>  >>> >> >> itsmeden@gmail.com
>>  >>> >> >> >> >:
>>  >>> >> >> >> >> >> > Hi Romain
>>  >>> >> >> >> >> >> >
>>  >>> >> >> >> >> >> > Thanks for 
> the link to the ManagedConnection, some
>>  >>> questions
>>  >>> >> on
>>  >>> >> >> it
>>  >>> >> >> >> >> (so I
>>  >>> >> >> >> >> >> > understand 
> it correctly)
>>  >>> >> >> >> >> >> >
>>  >>> >> >> >> >> >> > - The 
> connection is bound to the tx when the first
>>  >>> method is
>>  >>> >> >> >> called on
>>  >>> >> >> >> >> >> the
>>  >>> >> >> >> >> >> > connect 
> (except for toString, equals and hashcode),
>>  and
>>  >>> if
>>  >>> >> its
>>  >>> >> >> not
>>  >>> >> >> >> >> >> already
>>  >>> >> >> >> >> >> > bound, 
> correct?
>>  >>> >> >> >> >> >> > - Do I 
> understand correctly that I will always use
>>  (using
>>  >>> >> >> >> delegation
>>  >>> >> >> >> >> in
>>  >>> >> >> >> >> >> the
>>  >>> >> >> >> >> >> > proxy) the 
> same connection (the one bound to the tx)
>>  >>> >> regardless
>>  >>> >> >> of
>>  >>> >> >> >> if
>>  >>> >> >> >> >> I
>>  >>> >> >> >> >> >> use
>>  >>> >> >> >> >> >> > 
> getConnection()/close() multiple times within an EJB
>>  that
>>  >>> >> >> handles
>>  >>> >> >> >> tx?
>>  >>> >> >> >> >> >> > - In the 
> above case the connection I think I'm using
>>  >>> (when I
>>  >>> >> >> simple
>>  >>> >> >> >> >> look
>>  >>> >> >> >> >> >> at
>>  >>> >> >> >> >> >> > the code) is 
> returned to the pool and the bound one is
>>  >>> used?
>>  >>> >> >> >> >> >> >
>>  >>> >> >> >> >> >> > Where can I 
> get more understanding of the
>>  >>> TransactionManager
>>  >>> >> and
>>  >>> >> >> >> its
>>  >>> >> >> >> >> >> > relation to 
> the transactions annotated in the EJB?
>>  >>> >> >> >> >> >> >
>>  >>> >> >> >> >> >> > Very nice to 
> take a look at the code, really makes the
>>  >>> >> >> >> understanding
>>  >>> >> >> >> >> alot
>>  >>> >> >> >> >> >> > easier, 
> thanks!
>>  >>> >> >> >> >> >> >
>>  >>> >> >> >> >> >> > /LF
>>  >>> >> >> >> >> >> >
>>  >>> >> >> >> >> >> >
>>  >>> >> >> >> >> >> > On Wed, Oct 
> 15, 2014 at 1:03 AM, Romain Manni-Bucau <
>>  >>> >> >> >> >> >> 
> rmannibucau@gmail.com>
>>  >>> >> >> >> >> >> > wrote:
>>  >>> >> >> >> >> >> >
>>  >>> >> >> >> >> >> >> Hi
>>  >>> >> >> >> >> >> >>
>>  >>> >> >> >> >> >> >> this is 
> actually more bound to JTA (you can read
>>  >>> >> >> >> >> >> >>
>>  >>> >> >> >> >> >> >>
>>  >>> >> >> >> >> >>
>>  >>> >> >> >> >>
>>  >>> >> >> >>
>>  >>> >> >>
>>  >>> >>
>>  >>>
>> 
> http://svn.apache.org/repos/asf/tomee/tomee/trunk/container/openejb-core/src/main/java/org/apache/openejb/resource/jdbc/managed/local/ManagedConnection.java
>>  >>> >> >> >> >> >> >> )
>>  >>> >> >> >> >> >> >>
>>  >>> >> >> >> >> >> >>
>>  >>> >> >> >> >> >> >> 
> 2014-10-15 0:14 GMT+02:00 Lars-Fredrik Smedberg <
>>  >>> >> >> >> itsmeden@gmail.com
>>  >>> >> >> >> >> >:
>>  >>> >> >> >> >> >> >> > Hi
>>  >>> >> >> >> >> >> >> >
>>  >>> >> >> >> >> >> >> > 
> Using JDBC, creating a connection and setting it to
>>  >>> auto
>>  >>> >> >> commit
>>  >>> >> >> >> >> false
>>  >>> >> >> >> >> >> to
>>  >>> >> >> >> >> >> >> be
>>  >>> >> >> >> >> >> >> > 
> able to group more than one statement into a single
>>  >>> >> >> transaction
>>  >>> >> >> >> I
>>  >>> >> >> >> >> >> >> > 
> understand.
>>  >>> >> >> >> >> >> >> >
>>  >>> >> >> >> >> >> >> > - 
> Is it possible to compare that to an EJB with a
>>  >>> >> >> >> >> >> 
> @TransactionAttribute
>>  >>> >> >> >> >> >> >> > 
> set? I would like to understand more in detail how
>>  >>> the EJB
>>  >>> >> >> >> handles
>>  >>> >> >> >> >> >> >> > 
> transactions, datasources and connections "under
>>  the
>>  >>> >> hood".
>>  >>> >> >> >> >> >> >> > (it 
> all comes from a discussion with a DBA)
>>  >>> >> >> >> >> >> >> >
>>  >>> >> >> >> >> >> >> > If 
> I use @Resource to inject a Datasource and use
>>  to
>>  >>> >> >> retrieve a
>>  >>> >> >> >> >> >> >> 
> connection
>>  >>> >> >> >> >> >> >> > I 
> usually call close on it after I done using it,
>>  >>> >> >> >> >> >> >> >
>>  >>> >> >> >> >> >> >> > - 
> Will close on the connection actually close it
>>  or is
>>  >>> >> that
>>  >>> >> >> >> done at
>>  >>> >> >> >> >> >> the
>>  >>> >> >> >> >> >> >> > 
> commit of the transaction (assume we are in an EJB
>>  >>> with
>>  >>> >> >> >> >> >> >> > 
> @TransactionAttribute set)?
>>  >>> >> >> >> >> >> >>
>>  >>> >> >> >> >> >> >> will be 
> done later to support rollback
>>  >>> >> >> >> >> >> >>
>>  >>> >> >> >> >> >> >> > - 
> Will the container automatically set auto commit
>>  >>> false
>>  >>> >> to
>>  >>> >> >> any
>>  >>> >> >> >> >> >> >> 
> connections
>>  >>> >> >> >> >> >> >> > 
> retrieved within the transaction?
>>  >>> >> >> >> >> >> >>
>>  >>> >> >> >> >> >> >> all JTA 
> ones, can also depend on JPA provider config
>>  >>> >> >> >> >> >> >>
>>  >>> >> >> >> >> >> >> > - 
> ... and many more questions :)
>>  >>> >> >> >> >> >> >> >
>>  >>> >> >> >> >> >> >> > 
> Maybe I'm mixing the topics a bit but it would be
>>  >>> really
>>  >>> >> >> great
>>  >>> >> >> >> to
>>  >>> >> >> >> >> >> >> > 
> understand it all more in-depth to be able to have
>>  the
>>  >>> >> >> >> >> understanding
>>  >>> >> >> >> >> >> and
>>  >>> >> >> >> >> >> >> > 
> discuss it with the DBA.
>>  >>> >> >> >> >> >> >> >
>>  >>> >> >> >> >> >> >> > 
> Thanks
>>  >>> >> >> >> >> >> >> >
>>  >>> >> >> >> >> >> >> >
>>  >>> >> >> >> >> >> >> >
>>  >>> >> >> >> >> >> >> > --
>>  >>> >> >> >> >> >> >> > Med 
> vänlig hälsning / Best regards
>>  >>> >> >> >> >> >> >> >
>>  >>> >> >> >> >> >> >> > 
> Lars-Fredrik Smedberg
>>  >>> >> >> >> >> >> >> >
>>  >>> >> >> >> >> >> >> > 
> STATEMENT OF CONFIDENTIALITY:
>>  >>> >> >> >> >> >> >> > The 
> information contained in this electronic
>>  message
>>  >>> and
>>  >>> >> any
>>  >>> >> >> >> >> >> >> > 
> attachments to this message are intended for the
>>  >>> exclusive
>>  >>> >> >> use
>>  >>> >> >> >> of
>>  >>> >> >> >> >> the
>>  >>> >> >> >> >> >> >> > 
> address(es) and may contain confidential or
>>  privileged
>>  >>> >> >> >> >> information. If
>>  >>> >> >> >> >> >> >> > you 
> are not the intended recipient, please notify
>>  >>> >> >> Lars-Fredrik
>>  >>> >> >> >> >> >> Smedberg
>>  >>> >> >> >> >> >> >> > 
> immediately at itsmeden@gmail.com, and destroy all
>>  >>> >> copies of
>>  >>> >> >> >> this
>>  >>> >> >> >> >> >> >> > 
> message and any attachments.
>>  >>> >> >> >> >> >> >>
>>  >>> >> >> >> >> >> >
>>  >>> >> >> >> >> >> >
>>  >>> >> >> >> >> >> >
>>  >>> >> >> >> >> >> > --
>>  >>> >> >> >> >> >> > Med vänlig 
> hälsning / Best regards
>>  >>> >> >> >> >> >> >
>>  >>> >> >> >> >> >> > Lars-Fredrik 
> Smedberg
>>  >>> >> >> >> >> >> >
>>  >>> >> >> >> >> >> > STATEMENT OF 
> CONFIDENTIALITY:
>>  >>> >> >> >> >> >> > The 
> information contained in this electronic message
>>  and
>>  >>> any
>>  >>> >> >> >> >> >> > attachments 
> to this message are intended for the
>>  >>> exclusive
>>  >>> >> use
>>  >>> >> >> of
>>  >>> >> >> >> the
>>  >>> >> >> >> >> >> > address(es) 
> and may contain confidential or privileged
>>  >>> >> >> >> information. If
>>  >>> >> >> >> >> >> > you are not 
> the intended recipient, please notify
>>  >>> >> Lars-Fredrik
>>  >>> >> >> >> >> Smedberg
>>  >>> >> >> >> >> >> > immediately 
> at itsmeden@gmail.com, and destroy all
>>  >>> copies of
>>  >>> >> >> this
>>  >>> >> >> >> >> >> > message and 
> any attachments.
>>  >>> >> >> >> >> >>
>>  >>> >> >> >> >> >
>>  >>> >> >> >> >> >
>>  >>> >> >> >> >> >
>>  >>> >> >> >> >> > --
>>  >>> >> >> >> >> > Med vänlig hälsning / 
> Best regards
>>  >>> >> >> >> >> >
>>  >>> >> >> >> >> > Lars-Fredrik Smedberg
>>  >>> >> >> >> >> >
>>  >>> >> >> >> >> > STATEMENT OF 
> CONFIDENTIALITY:
>>  >>> >> >> >> >> > The information 
> contained in this electronic message and
>>  any
>>  >>> >> >> >> >> > attachments to this 
> message are intended for the
>>  exclusive
>>  >>> use
>>  >>> >> of
>>  >>> >> >> the
>>  >>> >> >> >> >> > address(es) and may 
> contain confidential or privileged
>>  >>> >> >> information. If
>>  >>> >> >> >> >> > you are not the 
> intended recipient, please notify
>>  >>> Lars-Fredrik
>>  >>> >> >> >> Smedberg
>>  >>> >> >> >> >> > immediately at 
> itsmeden@gmail.com, and destroy all
>>  copies
>>  >>> of
>>  >>> >> this
>>  >>> >> >> >> >> > message and any 
> attachments.
>>  >>> >> >> >> >>
>>  >>> >> >> >> >
>>  >>> >> >> >> >
>>  >>> >> >> >> >
>>  >>> >> >> >> > --
>>  >>> >> >> >> > Med vänlig hälsning / Best 
> regards
>>  >>> >> >> >> >
>>  >>> >> >> >> > Lars-Fredrik Smedberg
>>  >>> >> >> >> >
>>  >>> >> >> >> > STATEMENT OF CONFIDENTIALITY:
>>  >>> >> >> >> > The information contained in 
> this electronic message and any
>>  >>> >> >> >> > attachments to this message 
> are intended for the exclusive
>>  use
>>  >>> of
>>  >>> >> the
>>  >>> >> >> >> > address(es) and may contain 
> confidential or privileged
>>  >>> >> information. If
>>  >>> >> >> >> > you are not the intended 
> recipient, please notify
>>  Lars-Fredrik
>>  >>> >> >> Smedberg
>>  >>> >> >> >> > immediately at 
> itsmeden@gmail.com, and destroy all copies
>>  of
>>  >>> this
>>  >>> >> >> >> > message and any attachments.
>>  >>> >> >> >>
>>  >>> >> >> >
>>  >>> >> >> >
>>  >>> >> >> >
>>  >>> >> >> > --
>>  >>> >> >> > Med vänlig hälsning / Best regards
>>  >>> >> >> >
>>  >>> >> >> > Lars-Fredrik Smedberg
>>  >>> >> >> >
>>  >>> >> >> > STATEMENT OF CONFIDENTIALITY:
>>  >>> >> >> > The information contained in this 
> electronic message and any
>>  >>> >> >> > attachments to this message are 
> intended for the exclusive use
>>  of
>>  >>> the
>>  >>> >> >> > address(es) and may contain 
> confidential or privileged
>>  >>> information. If
>>  >>> >> >> > you are not the intended recipient, 
> please notify Lars-Fredrik
>>  >>> >> Smedberg
>>  >>> >> >> > immediately at itsmeden@gmail.com, and 
> destroy all copies of
>>  this
>>  >>> >> >> > message and any attachments.
>>  >>> >> >>
>>  >>> >> >
>>  >>> >> >
>>  >>> >> >
>>  >>> >> > --
>>  >>> >> > Med vänlig hälsning / Best regards
>>  >>> >> >
>>  >>> >> > Lars-Fredrik Smedberg
>>  >>> >> >
>>  >>> >> > STATEMENT OF CONFIDENTIALITY:
>>  >>> >> > The information contained in this electronic 
> message and any
>>  >>> >> > attachments to this message are intended for the 
> exclusive use of
>>  the
>>  >>> >> > address(es) and may contain confidential or 
> privileged
>>  information.
>>  >>> If
>>  >>> >> > you are not the intended recipient, please 
> notify Lars-Fredrik
>>  >>> Smedberg
>>  >>> >> > immediately at itsmeden@gmail.com, and destroy 
> all copies of this
>>  >>> >> > message and any attachments.
>>  >>> >>
>>  >>> >
>>  >>> >
>>  >>> >
>>  >>> > --
>>  >>> > Med vänlig hälsning / Best regards
>>  >>> >
>>  >>> > Lars-Fredrik Smedberg
>>  >>> >
>>  >>> > STATEMENT OF CONFIDENTIALITY:
>>  >>> > The information contained in this electronic message and 
> any
>>  >>> > attachments to this message are intended for the 
> exclusive use of the
>>  >>> > address(es) and may contain confidential or privileged 
> information.
>>  If
>>  >>> > you are not the intended recipient, please notify 
> Lars-Fredrik
>>  Smedberg
>>  >>> > immediately at itsmeden@gmail.com, and destroy all copies 
> of this
>>  >>> > message and any attachments.
>>  >>>
>>  >>
>>  >>
>>  >>
>>  >> --
>>  >> Med vänlig hälsning / Best regards
>>  >>
>>  >> Lars-Fredrik Smedberg
>>  >>
>>  >> STATEMENT OF CONFIDENTIALITY:
>>  >> The information contained in this electronic message and any
>>  >> attachments to this message are intended for the exclusive use of 
> the
>>  >> address(es) and may contain confidential or privileged 
> information. If
>>  >> you are not the intended recipient, please notify Lars-Fredrik 
> Smedberg
>>  >> immediately at itsmeden@gmail.com, and destroy all copies of this
>>  >> message and any attachments.
>>  >>
>>  >
>>  >
>>  >
>>  > --
>>  > Med vänlig hälsning / Best regards
>>  >
>>  > Lars-Fredrik Smedberg
>>  >
>>  > STATEMENT OF CONFIDENTIALITY:
>>  > The information contained in this electronic message and any
>>  > attachments to this message are intended for the exclusive use of the
>>  > address(es) and may contain confidential or privileged information. If
>>  > you are not the intended recipient, please notify Lars-Fredrik 
> Smedberg
>>  > immediately at itsmeden@gmail.com, and destroy all copies of this
>>  > message and any attachments.
>> 
> 
> 
> 
> -- 
> Med vänlig hälsning / Best regards
> 
> Lars-Fredrik Smedberg
> 
> STATEMENT OF CONFIDENTIALITY:
> The information contained in this electronic message and any
> attachments to this message are intended for the exclusive use of the
> address(es) and may contain confidential or privileged information. If
> you are not the intended recipient, please notify Lars-Fredrik Smedberg
> immediately at itsmeden@gmail.com, and destroy all copies of this
> message and any attachments.
> 

Mime
View raw message