tomee-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Lars-Fredrik Smedberg <itsme...@gmail.com>
Subject Re: JDBC Transactions vs EJBs and @TransactionAttribute(...) and more...
Date Sat, 18 Oct 2014 13:39:09 GMT
Thanks Mark

Will try that out.

/LF

On Fri, Oct 17, 2014 at 9:08 PM, Mark Struberg <struberg@yahoo.de> wrote:

> 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.
> >
>



-- 
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
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message